draft-ietf-mboned-rac-issues-01.txt   draft-ietf-mboned-rac-issues-02.txt 
Tsunemasa Hayashi, NTT Tsunemasa Hayashi, NTT
Internet Draft Haixiang He, Nortel Networks Internet Draft Haixiang He, Nortel Networks
Expires: April 15, 2006 Hiroaki Satou, NTT Expires: September 6, 2006 Hiroaki Satou, NTT
Hiroshi Ohta, NTT Hiroshi Ohta, NTT
Susheela Vaidya, Cisco Systems Susheela Vaidya, Cisco Systems
October 12, 2005 March 5, 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-01.txt> <draft-ietf-mboned-rac-issues-02.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
and may be updated, replaced, or obsolet ed by other documents at months and may be updated, replaced, or obsoleted by other documents
any time. It is inappropriate to use Internet-Drafts as reference at any time. It is inappropriate to use Internet-Drafts as
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 April 15, 2006. This Internet-Draft will expire on September 6, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005) Copyright (C) The Internet Society (2006)
Abstract Abstract
This I-D evaluates the extent to which current multicasting protocols This memo evaluates the extent to which current multicasting
can be used to address common requirements for commercial, large- protocols can be used to address common requirements for commercial,
scale IP multicasting. Four existing possible multicasting large-scale IP multicasting. 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 I-D 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 I-D non-standardized solutions to meet common use requirements. This
recommends for requirements to be defined that would set the memo recommends for requirements to be defined that would set the
groundwork for creating standardized ways to overcome these groundwork for framework(s) and solutions that sufficiently address
limitations. these 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..................................................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....................................................6 implementations....................................................7
4.1 Access limits and resource issues..............................6 4.1 Access limits and resource issues..............................7
4.2 Capability to distinguish between receivers (end hosts)........6 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).............................................................7
4.4 Channel "leave latency"........................................7 4.4 Minimizing Channel Join Latency and Leave Latency..............8
4.5 Surveillance of receiver by sender.............................7 4.5 Surveillance of receiver by sender.............................8
4.5.1 Precise access log...........................................7 4.5.1 Precise access logging.......................................8
4.5.2 How to share user information................................7 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....................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........9
4.7 Triple Play....................................................8 4.7 Sharing of Infrastructure for Support of Triple Play Services..9
4.8 DRM Protection.................................................8 4.8 DRM Protection.................................................9
5. Description of existing architectures...........................8 5. Description of existing architectures...........................9
5.1 IGMP/MLD.......................................................8 5.1 IGMP/MLD.......................................................9
5.2 IGMP/MLD plus L2/L3 Authentication with Access Control Policy.10 5.2 IGMP/MLD plus L2/L3 Authentication with Access Control Policy.11
5.3 Unicast Control with IGMP/MLD.................................11 5.3 Unicast Control with IGMP/MLD.................................12
5.4 IGMP/MLD with Multicast Encryption............................11 5.4 IGMP/MLD with Multicast Encryption............................13
6. Evaluation of architectures by issue...........................12 6. Evaluation of architectures by issue...........................14
6.1 Access limit capabilities, compared by architecture...........12 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......................................................13 architecture......................................................15
6.3 Capability to distinguish between users, compared by architecture 6.3 Capability to distinguish between users, compared by
..................................................................13 architecture......................................................16
6.4 Maintain guaranteed quality-level of data delivery (Voice, Video), 6.4 Maintain guaranteed quality-level of data delivery (Voice,
compared by architecture..........................................14 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
..................................................................14 ..................................................................17
6.6 Surveillance of receiver by sender, compared by architecture..15 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...................................................15 by architecture...................................................19
6.8 Comparison summary............................................16 6.8 Comparison summary............................................19
7. IANA considerations............................................16 7. IANA considerations............................................20
8. Security considerations........................................16 8. Security considerations........................................20
9. Conclusion.....................................................16 9. Conclusion.....................................................20
Normative References..............................................17 Normative References..............................................20
Full Copyright Statement..........................................19 Comments..........................................................22
Intellectual Property.............................................19 Full Copyright Statement..........................................23
Acknowledgement...................................................19 Intellectual Property.............................................23
Expiration........................................................24
Acknowledgement...................................................24
1. Introduction 1. Introduction
The intention of this I-D is to initiate a discussion on the state of The intention of this memo is to initiate a discussion on the state
current multicasting protocols deployed for commercial, large-scale of current multicasting protocols deployed for commercial, large-
multicasting and their capabilities to provide receiver access scale 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
include architectural considerations intended to support commercial necessarily include architectural considerations intended to support
services. This I-D presents a number of issues network providers may commercial services. This memo presents a number of issues network
face when they attempt to apply current multicasting standards to providers may face when they attempt to apply current multicasting
commercial services. The extent to which existing multicast standards to commercial services. The extent to which existing
protocols can or cannot satisfactorily deal with these issues is multicast protocols can or cannot satisfactorily deal with these
explored. A few network models based on a range of different issues is explored. A few network models based on a range of
business models are presented as a basis for defining requirements. different 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
of receivers. However, multicasting according to current standards number of receivers. However, multicasting according to current
(e.g., IGMPv3[1] and MLDv2[2]) has drawbacks compared to unicasting standards (e.g., IGMPv3[1] and MLDv2[2]) has drawbacks compared to
in terms of its commercial applicability because of the insufficiency unicasting in terms of its commercial applicability because of the
of access control and protect network resources against malicious use insufficiency of access control and protection of network resources
or accidents. In order to be applicable to large-scale commercial against malicious use or accidents. In order to be applicable to
networks, multicast networks need to have the same capabilities which large-scale commercial networks, multicast networks need to have the
are currently supported by unicast networks. Such issues which are same capabilities which are currently supported by unicast networks.
important to commercial, large-scale implementations of multicasting Such issues which are important to commercial, large-scale
are listed. Next, a few possible existing architectures used for implementations of multicasting are listed. Next, a few possible
multicasting with access control based on current standards are existing architectures used for multicasting with access control
presented. Specifically 1) IGMP/ MLD, 2) IGMP/MLD with L2 based on current standards are presented. Specifically 1) IGMP/ MLD,
Authentication with ACL 3) Unicast Control with IGMP/MLD and 4) 2) IGMP/MLD with L2/L3 Authentication with ACL 3) Unicast Control
IGMP/MLD with Multicast Encryption will each be presented and with IGMP/MLD and 4) IGMP/MLD with Multicast Encryption will each be
described. Each architecture is discussed with respect to the presented and described. Each architecture is discussed with
presented list of issues. 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 memo 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.
Authentication: action for identifying a user as a genuine one. Authentication: action for identifying a user as a genuine one.
Authorization: action for giving permission to access the content or Authorization: action for giving permission to access the content or
network to a user. network to a user.
Receiver: an end-host or end-client which receives content. A Receiver: an end-host or end-client which receives content. A
receiver may be distinguishable by a network ID such as MAC address receiver may be distinguishable by a network ID such as MAC address
or IP address. or IP address.
Triple Play: voice (VoIP), video, and broadband Internet access
services.
User: a human with a user account. A user may possibly use multiple User: a human with a user account. A user may possibly use multiple
reception devices. Multiple users may use the same reception device. reception devices. Multiple users may use the same reception device.
Note: The definition of a receiver (device) and a user (human) should Note: The definition of a receiver (device) and a user (human)
not be confused. should not be confused.
2.2 Abbreviations 2.2 Abbreviations
For the purposes of this draft the following abbreviations apply: For the purposes of this draft the following abbreviations apply:
ACL: Access Control List ACL: Access Control List
CDS: Content Delivery Services CDS: Content Delivery Services
CSP: Content Service Provider CP: Content 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.
skipping to change at page 5, line 17 skipping to change at page 5, line 40
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
mechanisms. In many cases however the content provision and network control mechanisms. In many cases however the content provision and
provision roles are divided between separate entities. The I-D network provision roles are divided between separate entities. The
draft-ietf-mboned-maccnt-00.txt provides more detail of the multiple 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. 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
are the same. Indeed because the infrastructure for multicasting is serving are the same. Indeed because the infrastructure for
expensive and many content holders are not likely to be competent at multicasting is expensive and many content holders are not likely to
building and maintaining complicated infrastructures necessary for be competent at building and maintaining complicated infrastructures
multicasting, many content holders would prefer to purchase transport necessary for multicasting, many content holders would prefer to
and management services from a network service provider and thus purchase transport and management services from a network service
share the infrastructure costs with other content holders. provider and thus share the infrastructure costs with other content
holders.
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 network service provider (NSP)
multiple CSP has certain implications: providing multicasting services to multiple content providers CP 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 CP
-Methods for sharing information between the NSP and CSP to make -Methods for sharing information between the NSP and CP to make
the above two possible the above two possible
When the NSP and CSP are the same single entity the general When the NSP and CP 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 the
entity deems appropriate 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
not pertinent to cases where the NSP and CSP are the same entity. are not pertinent to cases where the NSP and CP 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. To avoid unnecessary
requirements related to these issues are provided in a separate I-D duplication with MACCNT-draft, detail for some of these issues is
draft-ietf-mboned-maccnt-00.txt[3]. References to that document are provided through references in the Normative Reference section.
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
host can access at the same time. Also the network provider may wish a host can access at the same time. Also the network provider may
to limit the number of users accessing a multicast stream because of wish to limit the number of users accessing a multicast stream
bandwidth and processing issues between the receiver and the because of bandwidth and processing issues between the receiver and
multicast server. 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 With best-effort services (e.g. mail transfer, web surfing) strict
network resource allocation is not necessary, but for services with a network resource allocation is not necessary, but for services with
guaranteed QoS level (e.g. IP television, teleconferencing, VoIP) it a guaranteed QoS level (e.g. IP television, teleconferencing, VoIP)
is necessary to allocate sufficient bandwidth and server resources to it is necessary to allocate sufficient bandwidth and server
each service. In order to guarantee certain QoS levels, it is resources to each service. More detail on the topic of network
important for network providers to be able to protect their network resource protection is provided in section "Issue of network
resources from being wasted (either maliciously or accidentally). resource protection" of the MACCNT-draft[3].
More detail on this topic is provided in I-D draft-ietf-mboned-
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) For detail on the topic on the capability to distinguish between
are actually receiving its information with existing protocols receivers, refer to MACCNT-draft[3], 4.1 the second paragraph which
(IGMP/MLD.) The sender must rely on the information from the begins with "With current protocols (IGMP/MLD), the sender cannot
multicasting routers. This can be complicated if the sender and distinguish
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 4.3 Capability to distinguish between users (as opposed to merely
hosts) hosts)
Detail related to the topic of user identification can be found in
section "User identification" of the MACCNT-draft[3], the first
paragraph.
Many content providers would like to have detailed information on 4.4 Minimizing Channel Join Latency and Leave Latency
which users (as opposed to merely hosts identified by physical
addresses, etc.) are consuming their content and information on
their usage behavior. More detail on this topic can be found in I-D
draft-ietf-mboned-maccnt-00.txt, section "User identification."
4.4 Channel "leave latency"
Commercial implementations of IP multicasting are likely to have More detail on the topic of channel leave latency is provided in
strict requirements in terms of user experience. Leave latency is section "Channel Join Latency and Leave Latency" of the MACCNT-
the time between when a user sends a signal that he/she wishes to draft[3].
"leave" a group and when the network recognizes the "leave."
A separate I-D draft-ietf-mboned-maccnt-00.txt provides more detail
on this topic in the section "Channel 'leave latency'"
4.5 Surveillance of receiver by sender 4.5 Surveillance of receiver by sender
4.5.1 Precise access log 4.5.1 Precise access logging
It is necessary to precisely log information such as who (host/user) For detail on the topic please refer to MACCNT-draft[3], 4.6
is accessing what content at from what time (join action) until what "Accounting and billing", especially the second paragraph which
time (leave action). The result of the access-control decision (e.g. begins with "To assemble such..."
results of authorization) would also be valuable information.
4.5.2 How to share user information 4.5.2 How to share user information
For commercial multicast applications where NSP and CSP are different For commercial multicast applications where NSP and CP are different
entities, there are a number of issues regarding how to share user entities, there are a number of issues regarding how to share user
information between the NSP and CSP. For example, which entities information between the NSP and CP. For example, which entities
should be able to access which information relating to user-based should be able to access which information relating to user-based
tracking? What is the user identifier that can be used between the tracking? What is the user identifier that can be used between the
entities to distinguish among users, and which entities should be entities to distinguish among users, and which entities should be
able to recognize this identifier? Another important issue is how able to recognize this identifier? Another important issue is how
the edge router should be able to access and then maintain user the edge router should be able to access and then maintain user
information. The current situation of present architectures is that information. The current situation of present architectures is that
only the NSP can get information about user activity, because user only the NSP can get information about user activity, because user
activities are only observable from join/leave information logged on activities are only observable from join/leave information logged on
edge devices which are under control of the NSP. edge devices which are under control of the NSP. This section
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 4.5.3 Trustworthy logs to monitor user activity
An important issue for commercial multicasting applications is how An important issue for commercial multicasting applications is how
the NSP can get trustworthy data on user activity which may be needed the NSP can get trustworthy data on user activity which may be
for billing and statistics purposes. A standard way of logging user needed for billing and statistics purposes. A standard way of
activity and protecting the integrity of the logs does not exist. logging user activity and protecting the integrity of the logs does
Often network providers do not want to keep logs on untrusted user not exist. Often network providers do not want to keep logs on
terminals which can be tampered with. untrusted user terminals that can be tampered with.
4.6 Notification to users of the result of the join request 4.6 Notification to users of the result of the join request
It is necessary to provide information to the user about the status Details for this issue are presented in MACCNT-draft[3], section 4.6
of his/her join request(granted/denied/other). "Notification to users of the result of the join request."
4.7 Triple Play 4.7 Sharing of Infrastructure for Support of Triple Play Services
Ideally the NSP should be able to use the same infrastructure (such As stated in MACCNT-draft[3], section "Small impact on the existing
as access control) to support commercial multicast services for the products": "Ideally the NSP should be able to use the same
so-called "triple play" services: voice (VoIP), video, and broadband infrastructure (such as access control) to support commercial
Internet access services. multicast services for the so-called 'triple play' services".
4.8 DRM Protection 4.8 DRM Protection
Digital Rights Management (DRM) is important but out of scope of this Digital Rights Management (DRM) is important but out of scope of
I-D. this memo.
5. Description of existing architectures 5. Description of existing architectures
In this section, existing architectures used for multicasting based In this section, existing architectures used for multicasting based
on current standards are defined. In section 6 these architectures on current standards are defined. In section 6 these architectures
will be compared by the issues presented in section 4. will be compared by the issues presented in section 4.
5.1 IGMP/MLD 5.1 IGMP/MLD
Internet Group Management Protocol(IGMP) or Multicast Listener Internet Group Management Protocol(IGMP) or Multicast Listener
skipping to change at page 9, line 14 skipping to change at page 10, line 17
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+ +----------+ +----------+
| Sender | | Router | | L2SW | | Receiver | | Sender | | Router | | L2SW | | Receiver |
| | | |<---------------1,JOIN--| | | | | |<---------------1,JOIN--| |
| | | | | | | | | | | | | | | |
| |--------------------------------2,Data->| | | |--------------------------------2,Data->| |
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+ +----------+ +----------+
For the sake of simplicity, the above diagram only shows the sequence For the sake of simplicity, the above diagram only shows the
of requests for a single receiver. When multiple receivers are sequence of requests for a single receiver. When multiple receivers
requesting the same channel stream the data would be copied at the are requesting the same channel stream the data would be copied at
multicasting router to serve the multiple streams. the multicasting router to serve the multiple streams.
5.2 IGMP/MLD plus L2/L3 Authentication with Access Control Policy 5.2 IGMP/MLD plus L2/L3 Authentication with Access Control Policy
With a basic implementation of IGMP/MLD implementation, no With a basic implementation of IGMP/MLD, no authorization is
authorization is performed on the receiver. It is possible to performed on the receiver. It is possible to combine an IGMP/MLD
combine an IGMP/MLD implementation with Layer 2 or Layer 3 implementation with Layer 2 or Layer 3 Authentication to provide an
Authentication to provide an access-control mechanism at the first access-control mechanism at the first point of attachment to the
point of attachment to the network, for example, using 802.X. network, for example, using 802.1X.
For example, a receiver may request to an L2 authentication server For example, a receiver may request to an L2 authentication server
for access to the network. The authentication controller then queries for access to the network. The authentication controller then
the policy server with the receiver's credentials (such as IP or MAC queries the policy server with the receiver's credentials (such as
address), and if the receiver is determined to be an authorized user IP or MAC address), and if the receiver is determined to be an
of the network ("success"), the router downloads the ACL from the authorized user of the network ("success"), the router downloads the
policy sever. For example, users which are not on the ACL are ACL from the policy server. For example, users which are not on the
rejected. Then the Layer 2 Switch is directed to open a port for the ACL are rejected. Then the Layer 2 Switch is directed to open a
receiver to send a join request to the multicast router. The router port for the receiver to send a join request to the multicast router.
is then responsible for forwarding the appropriate data from the The router is then responsible for forwarding the appropriate data
sender to the receiver. from the sender to the receiver.
Note: ACL is one existing method to realize an access control policy. Note: ACL is one existing method to realize an access control policy.
Other methods exist. Other methods exist.
+----------+ +----------+
| Policy | | Policy |
| Server |\ | Server |\
| | \ | | \
+----------+ \ 4,ACL Download +----------+ \ 4,ACL Download
| ^ \ | ^ \
skipping to change at page 11, line 9 skipping to change at page 12, line 36
+----------+ +--------|-+ +----------+ +----------+ +----------+ +--------|-+ +----------+ +----------+
| |
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. 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 | | Sender | | Router | | L2SW | | Receiver |
| | | | | | | | | | | | | | | |
| |<------------------------------1,Request-| | | |<------------------------------1,Request-| |
| | | | | | | | | | | | | | | |
| |-------------------------------2,Success>| | | |-------------------------------2,Success>| |
| | | | | | | | | | | | | | | |
| | | |<--------------3,Join----| | | | | |<--------------3,Join----| |
| | | | | | | | | | | | | | | |
| |------------>x-----------------4,Data--->| | | |------------>x-----------------4,Data--->| |
skipping to change at page 13, line 16 skipping to change at page 15, line 24
wasted if an ineligible receiver receives an encrypted content even wasted if an ineligible receiver receives an encrypted content even
if they do not have a valid key. if they do not have a valid key.
6.2 Capability to distinguish between receivers, compared by 6.2 Capability to distinguish between receivers, compared by
architecture architecture
Comparison of currently possible protocol-based solutions. Comparison of currently possible protocol-based solutions.
-IGMP/MLD: -IGMP/MLD:
The sender has no direct line of contact with the receiver and The sender has no direct line of contact with the receiver and
therefore cannot distinguish on a receiver-basis. (If the therefore cannot distinguish on a receiver-basis. (If the edge-
interface is fixed to the receiver then the join-log can be used, but router's user interface is statically assigned then the interface's
this would mean portability is sacrificed. Moreover, this method is log can be used to track joins, but this would mean portability is
not applicable to a case where the CSP and NSP are different sacrificed. Moreover, this method is not applicable to a case where
companies because CSP cannot access this join-log.) 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: -L2/L3 authentication with access control policy:
At the moment of L2/L3 authentication it is possible to recognize At the moment of L2/L3 authentication it is possible to recognize
receivers, but if there are multiple content service providers (CSP) receivers, but if there are multiple content providers (CP) a single
a single L2 Authorization Server cannot distinguish among the CSPs. L2 Authorization Server cannot distinguish among the CPs. Therefore
Therefore it would be necessary to gather the join logs. (If the it would be necessary to gather the join logs. (If the interface is
interface is fixed then the join-log can be used, but this would mean fixed then the join-log can be used, but this would mean portability
portability is sacrificed. Moreover, this method is not applicable is sacrificed. Moreover, this method is not applicable to a case
to a case where the CSP and NSP are different companies because the where the CP and NSP are different companies because the CP cannot
CSP cannot access this join-log.) access this join-log.)
-IGMP/MLD with Unicast control : -IGMP/MLD with Unicast control :
It is possible to distinguish among receivers using Unicast control. 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: -Multicast Encryption:
If the Content Service Provider maintains the Key Server it is If the CP maintains the Key Server it is possible to distinguish on
possible to distinguish on the receiver-level. If the Network the receiver-level. If the Network Service Provider maintains the
Service Provider maintains the key server it is necessary to devise a key server it is necessary to devise a method for the NSP to notify
method for the NSP to notify the CSP. the CP.
6.3 Capability to distinguish between users, compared by architecture 6.3 Capability to distinguish between users, compared by architecture
Comparison of currently possible protocol-based solutions: Comparison of currently possible protocol-based solutions:
-IGMP/MLD: -IGMP/MLD:
Since there is no user-based information, it is not possible to Since there is no user-based information, it is not possible to
distinguish on the user-level. distinguish on the user-level.
-L2/L3 authentication with access control policy: -L2/L3 authentication with access control policy:
skipping to change at page 14, line 30 skipping to change at page 17, line 17
Comparison of currently possible protocol-based solutions: Comparison of currently possible protocol-based solutions:
-IGMP/MLD: -IGMP/MLD:
It is not possible to reject a user attempting to access even if It is not possible to reject a user attempting to access even if
there are not sufficient resources. there are not sufficient resources.
-L2/L3 authentication with access control policy: -L2/L3 authentication with access control policy:
The AAA server does not know whether there are sufficient resources The AAA server does not know whether there are sufficient resources
or not. This method still can provide a guaranteed QoS if every or not. This method still can provide a guaranteed QoS if every
channel has the same bandwidth and sufficient bandwidth are allocated channel has the same bandwidth and sufficient bandwidth are
to each user beforehand. However, it is not possible to provide a allocated to each user beforehand. However, it is not possible to
guaranteed QoS by comparing the available bandwidth and the necessary provide a guaranteed QoS by comparing the available bandwidth and
bandwidth upon each user's request. the necessary bandwidth upon each user's request.
-IGMP/MLD with Unicast control : -IGMP/MLD with Unicast control :
When the CSP and NSP are separate entities it is not possible for the When the CP and NSP are separate entities it is not possible for the
CSP to make a proper authorization decision because only the NSP CP to make a proper authorization decision because only the NSP
grasps the network resource availability. grasps the network resource availability.
-Multicast Encryption: -Multicast Encryption:
It is not possible to reject a user attempting to access even if Having only encryption provides no access control and therefore
there are not sufficient resources because the user can receive data provides no mechanism to reject a user attempt to access when
even without a valid key. 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 6.5 Fast leave for fast surfing capability, compared by architecture
Comparison of currently possible protocol-based solutions: Comparison of currently possible protocol-based solutions:
-IGMP/MLD: -IGMP/MLD:
It is possible to track on a per host level (based on host address) It is possible to track on a per host level (based on host address)
therefore fast leave for fast surfing capability can be achieved. therefore fast leave for fast surfing capability can be achieved.
-L2/L3 authentication with access control policy: -L2/L3 authentication with access control policy:
It is possible to track on a per host level (based on host address) It is possible to track on a per host level (based on host address)
therefore fast leave for fast surfing capability can be achieved. therefore fast leave for fast surfing capability can be achieved.
-IGMP/MLD with Unicast control : -IGMP/MLD with Unicast control :
Even if a quick leave is possible, changing to a new channel using Even if a quick leave is possible, changing to a new channel using
Unicast Control is slow (latency problem). 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: -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 separately log 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
because analyzing the logs requires heavy computation (related to the because analyzing the logs requires heavy computation (related to
scalability with millions of users). the 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 logout
messages. In this case, it is not possible to determine when each messages. Also it is possible that the user is running multiple
user's entry in the ACL should be deactivated. 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.
-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.
-Multicast Encryption: -Multicast Encryption:
If logs are recorded for each renewal of keys, then it is possible to If logs are recorded for each renewal of keys, then it is possible
track activity on a per-user basis. However if logs are only recorded to track activity on a per-user basis. However if logs are only
per content data download then such tracking is not possible. recorded per content data download then such tracking is not
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 of After the join it is not possible to notify the user of the result
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 of After the join it is not possible to notify the user of the result
the join request. of the join request.
-IGMP/MLD with Unicast control : -IGMP/MLD with Unicast control :
After the join it is not possible to notify the user of the result of After the join it is not possible to notify the user of the result
the join request. of the join request.
-Multicast Encryption: -Multicast Encryption:
After the join it is not possible to notify the user of the result of After the join it is not possible to notify the user of the result
the join request. of the join request.
6.8 Comparison summary 6.8 Comparison summary
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 recommended commercial, large-scale IP multicasting. Therefore it is
that framework(s) for sufficiently addressing such requirements be recommended that framework(s) for sufficiently addressing such
explored. requirements be explored.
7. IANA considerations 7. IANA considerations
This I-D does not raise any IANA consideration issues. This memo does not raise any IANA consideration issues.
8. Security considerations 8. Security considerations
This I-D does not raise any new security issues which are not already This memo does not raise any new security issues which are not
existing in original protocols. Enhancement of multicast access already existing in original protocols. Enhancement of multicast
control capabilities may enhance security performance. access control capabilities may enhance security performance.
9. Conclusion 9. 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 these is often necessary to deploy non-standardized solutions to meet
common requirements. It is recommended that requirements be defined these common requirements. It is recommended that requirements be
to serve as a basis for creating standardized ways to address the defined to set the groundwork for creating framework(s) and
various issues discussed in this I-D which are limiting the solutions that address the various issues discussed in this memo
application of multicasting especially to commercial, large-scale CDS which are limiting the application of multicasting especially to
services. Such requirements should take into consideration a range of commercial, large-scale CDS services. Such requirements should take
possible architectures based on multiple business or usage models. into consideration a range of possible architectures based on
multiple business or usage models.
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
RFC3376, October 2002. 3", RFC3376, October 2002.
[2] R. Vida, et. al., "Multicast Listener Discovery Version 2 (MLDv2) [2] R. Vida, et. al., "Multicast Listener Discovery Version 2
for IPv6", RFC3810, June 2004. (MLDv2) 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-01.txt, October 2005 [Work in Progress]. mboned-maccnt-req-04.txt, February 2006 [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 19, line 7 skipping to change at page 23, line 7
Phone: +1-408-525-1952 Phone: +1-408-525-1952
Email: svaidya@cisco.com Email: svaidya@cisco.com
Comments Comments
Comments are solicited and should be addressed to the mboned working Comments are solicited and should be addressed to the mboned working
group's mailing list at mboned@lists.uoregon.edu_and/or the authors. group's mailing list at mboned@lists.uoregon.edu_and/or the authors.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed
pertain to the implementation or use of the technology described in to pertain to the implementation or use of the technology described
this document or the extent to which any license under such rights in this document or the extent to which any license under such
might or might not be available; nor does it represent that it has rights might or might not be available; nor does it represent that
made any independent effort to identify any such rights. Information it has made any independent effort to identify any such rights.
on the IETF's procedures with respect to rights in IETF Documents can Information on the procedures with respect to rights in RFC
be found in BCP 78 and BCP 79. documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an 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 attempt made to obtain a general license or permission for the use
such proprietary rights by implementers or users of this of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository
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 April 15, 2006. This Internet-Draft will expire on September 6, 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. 85 change blocks. 
263 lines changed or deleted 296 lines changed or added

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