draft-ietf-mboned-multiaaa-framework-10.txt   draft-ietf-mboned-multiaaa-framework-11.txt 
mboned T. Hayashi mboned H. Satou,
Internet-Draft NTT Network Innovation Internet-Draft H. Ohta,
Intended status: Informational Laboratories Intended status: Informational T. Hayashi,
Expires: February 5, 2010 H. He Expires: September 6, 2010 NTT
Nortel C. Jacquenet
H. Satou France Telecom
H. Ohta H. He
NTT Network Service Systems Nortel
Laboratories
C. Jacquenet March 5, 2010
France Telecom
August 4, 2009
AAA and Admission Control Framework for Multicasting AAA and Admission Control Framework for Multicasting
draft-ietf-mboned-multiaaa-framework-10 draft-ietf-mboned-multiaaa-framework-11
Abstract
IP multicast-based services, such as TV broadcasting or
videoconferencing raise the issue of making sure that potential
customers are fully entitled to access the corresponding contents.
There is indeed a need for service and content providers to identify
users (if not authenticate, especially within the context of
enforcing electronic payment schemes) and to retrieve statistical
information for accounting purposes, as far as content and network
usage are concerned. This memo describes the framework for
specifying the Authentication, Authorization and Accounting (AAA)
capabilities that could be activated within the context of the
deployment and the operation of IP multicast-based services. This
framework addresses the requirements presented in "Requirements for
Accounting, Authentication and Authorization in Well Managed IP
Multicasting Services" [I-D.ietf-mboned-maccnt-req]. The memo
provides a basic AAA enabled model as well as an extended fully
enabled model with resource and admission control coordination.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79.
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
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- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 5, 2010. This Internet-Draft will expire on September 6, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
IP multicast-based services, such as TV broadcasting or
videoconferencing raise the issue of making sure that potential
customers are fully entitled to access the corresponding contents.
There is indeed a need for service and content providers to identify
users (if not authenticate, especially within the context of
enforcing electronic payment schemes) and to retrieve statistical
information for accounting purposes, as far as content and network
usage are concerned. This memo describes the framework for
specifying the Authorization, Authentication and Accounting (AAA)
capabilities that could be activated within the context of the
deployment and the operation of IP multicast-based services. This
framework addresses the requirements presented in "Requirements for
Accounting, Authentication and Authorization in Well Managed IP
Multicasting Services" [I-D.ietf-mboned-maccnt-req]. The memo
provides a basic AAA enabled model as well as an extended fully
enabled model with resource and admission control coordination.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Purpose and Background . . . . . . . . . . . . . . . . . . 4 1.1. Purpose and Background . . . . . . . . . . . . . . . . . . 3
2. Definitions and Abbreviations . . . . . . . . . . . . . . . . 5 2. Definitions and Abbreviations . . . . . . . . . . . . . . . . 4
2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5
3. Common use models and network architecture implications . . . 7 3. Common use models and network architecture implications . . . 6
4. Framework and Roles of Entities . . . . . . . . . . . . . . . 8 4. Framework and Roles of Entities . . . . . . . . . . . . . . . 7
4.1. AAA Framework in Multicast-Enabled Environments . . . . . 8 4.1. AAA Framework in Multicast-Enabled Environments . . . . . 7
4.2. User ID . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2. User ID . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3. Accounting . . . . . . . . . . . . . . . . . . . . . . . . 11 4.3. Accounting . . . . . . . . . . . . . . . . . . . . . . . . 11
4.4. Access Control and CP selection by NSP . . . . . . . . . . 12 4.4. Access Control and CP selection by NSP . . . . . . . . . . 12
4.5. Admission Control Information by NSP . . . . . . . . . . . 13 4.5. Admission Control Information by NSP . . . . . . . . . . . 12
4.6. Access Control and Distinguishing of Users by CP . . . . . 14 4.6. Access Control and Distinguishing of Users by CP . . . . . 13
4.7. AAA proxy in NSP . . . . . . . . . . . . . . . . . . . . . 14 4.7. AAA proxy in NSP . . . . . . . . . . . . . . . . . . . . . 13
5. Network Connection Model and Functional Components . . . . . . 14 5. Network Connection Model and Functional Components . . . . . . 14
5.1. Basic Connection Model . . . . . . . . . . . . . . . . . . 15 5.1. Basic Connection Model . . . . . . . . . . . . . . . . . . 14
5.2. Constituent Logical Functional Components of the fully 5.2. Constituent Logical Functional Components of the fully
enabled AAA Framework . . . . . . . . . . . . . . . . . . 16 enabled AAA Framework . . . . . . . . . . . . . . . . . . 15
5.3. Modularity of the framework . . . . . . . . . . . . . . . 20 5.3. Modularity of the framework . . . . . . . . . . . . . . . 19
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 20 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
9. Normative References . . . . . . . . . . . . . . . . . . . . . 20 9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 10. Normative References . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . . . 22
1. Introduction 1. Introduction
1.1. Purpose and Background 1.1. Purpose and Background
IP multicasting is designed to serve cases of group communication IP multicasting is designed to serve cases of group communication
schemes of any kind, such as one-to-many (case of TV broadcasting schemes of any kind, such as one-to-many (case of TV broadcasting
services for example) or many-to- many (case of videoconferencing services for example) or many-to- many (case of videoconferencing
services, for example). services, for example).
skipping to change at page 9, line 21 skipping to change at page 8, line 21
The content may be associated with (or managed by) a specific CP. In The content may be associated with (or managed by) a specific CP. In
this case, when the user selects content, the CP is automatically this case, when the user selects content, the CP is automatically
selected. selected.
Requests for multicast sent by the user to a selected NSP should Requests for multicast sent by the user to a selected NSP should
include enough information not only for authentication by the CP but include enough information not only for authentication by the CP but
also for CP selection and admission control by the NSP. also for CP selection and admission control by the NSP.
When an NSP receives a request for multicast from a user, the NSP When an NSP receives a request for multicast from a user, the NSP
requests the appropriate CP to make sure that the user is entitled to requests the appropriate CP to make sure that the user is entitled to
access the corresponding content As the NSP is responsible for access the corresponding content as the NSP is responsible for
managing its network resources, the NSP may perform admission managing its network resources, the NSP may perform admission
control.The NSP will allow access to the multicast service, depending control.The NSP will allow access to the multicast service, depending
on both the response sent by the CP and the availability of resources on both the response sent by the CP and the availability of resources
operated by the NSP. That is, the NSP will forward multicast traffic operated by the NSP. That is, the NSP will forward multicast traffic
towards the user only when the NSP has 1) made sure the user is towards the user only when the NSP has 1) made sure the user is
entitled to access the network resources operated by the NSP, 2) entitled to access the network resources operated by the NSP, 2)
received a confirmation from the CP that the user is entitled to received a confirmation from the CP that the user is entitled to
access the content and (possibly) 3) determined that the network access the content and (possibly) 3) determined that the network
resources (e.g. bandwidth) are sufficient to deliver the multicast resources (e.g. bandwidth) are sufficient to deliver the multicast
traffic to the user with the relevant level of quality. When neither traffic to the user with the relevant level of quality. When neither
skipping to change at page 10, line 29 skipping to change at page 9, line 29
selected. selected.
The user should send a request for multicast to the specific NSP with The user should send a request for multicast to the specific NSP with
enough information not only for authentication by the CP but also for enough information not only for authentication by the CP but also for
CP selection and admission control by the NSP. CP selection and admission control by the NSP.
The role of the NSP is the same as that described in 4.1.1. The role of the NSP is the same as that described in 4.1.1.
The role of a CP is the same as that described in 4.1.1. The role of a CP is the same as that described in 4.1.1.
4.1.3. Multiple CPs are connected to a single NSP 4.1.3. A single CP is connected to multiple NSPs
In this usage case, a user subscribes to multiple NSPs but only a In this usage case, a user subscribes to multiple NSPs but only a
single CP. A user selects the NSP when the user requests multicast single CP. A user selects the NSP when the user requests multicast
but the CP is fixed. The user should send a request for multicast to but the CP is fixed. The user should send a request for multicast to
the selected NSP with enough information not only for authentication the selected NSP with enough information not only for authentication
by the CP but also for admission control by the NSP. by the CP but also for admission control by the NSP.
The role of the NSP is similar to the description in 4.1.1, with the The role of the NSP is similar to the description in 4.1.1, with the
exception that when a NSP receives a request from a user, NSP makes exception that when a NSP receives a request from a user, NSP makes
an inquiry to the CP without CP selection. an inquiry to the CP without CP selection.
skipping to change at page 11, line 44 skipping to change at page 10, line 44
multicast to a NSP, the NSP-assigned user ID may be indicated in the multicast to a NSP, the NSP-assigned user ID may be indicated in the
request so that the NSP can identify the user. The NSP should not request so that the NSP can identify the user. The NSP should not
inform the NSP- assigned user ID to the CP for security reasons. The inform the NSP- assigned user ID to the CP for security reasons. The
NSP may identify the multicast-access user by other methods than the NSP may identify the multicast-access user by other methods than the
NSP-assigned userID, e.g. by the access port. NSP-assigned userID, e.g. by the access port.
The actual mapping rules for NSP-assigned user IDs with CP- user The actual mapping rules for NSP-assigned user IDs with CP- user
assigned IDs in account logs is a matter for the providers and out of assigned IDs in account logs is a matter for the providers and out of
the scope of this framework. the scope of this framework.
This memo assumes that the NSP identifies the user on L2 (such as
VLAN or PPP) and that it would be problematic for the NSP if more
than two receivers for the same user accessed the same channel and
one is accepted but the other is rejected on L2 or L3. Prevention of
unauthorized content sharing could be handled on the application
layer by the CP: e.g. could distinguish among receivers and
distribute encryption keys so that non-authorized receivers can not
make use of the content.
4.3. Accounting 4.3. Accounting
There are some accounting issues specific to multicasting. An (S,G) There are some accounting issues specific to multicasting. An (S,G)
should be recorded as a channel identifier. The last hop device, should be recorded as a channel identifier. The last hop device,
such as an IGMP or MLD router or an IGMP or MLD proxy, notifies the such as an IGMP or MLD router or an IGMP or MLD proxy, notifies the
NSP's mAAA function of the (S,G) channel identifier. The NSP should NSP's mAAA function of the (S,G) channel identifier. The NSP should
notify the CP of the (S,G) information in the accounting report notify the CP of the (S,G) information in the accounting report
messages. messages.
A NSP records an accounting start corresponding to only the first A NSP records an accounting start corresponding to only the first
Join for a specific user-access session. A NSP should not treat a Join for a specific user-access session. A NSP should not treat a
"Join" response to a Query as the accounting start. "Join" response to a Query as the accounting start. The accounting
start assumes that the conditions for forwarding multicast traffic as
defined in section 4.1.1 have been met: (1) user is entitled to
access network, 2) user is entitled to access content, optionally 3)
network resources are determined to be sufficient, and that the
forwarding has actually begun. Optionally a NSP may record when a
Join could not be granted because of insufficient network resources.
A NSP records an accounting stop triggered by any of the following: A NSP records an accounting stop triggered by any of the following:
1) a user requested Leave, 2) a timeout of a multicast state or 3) a 1) a user requested Leave, 2) a timeout of a multicast state or 3) a
re-authentication failure. A NSP may also record an accounting stop re-authentication failure. A NSP may also record an accounting stop
due to network availability reasons such as failure. The NSP logs due to network availability reasons such as failure. The NSP logs
the reason for each accounting stop. the reason for each accounting stop.
Intermittent logs between the join and leave would allow for finer Intermittent logs between the join and leave would allow for finer
diagnostics and therefore could serve useful in billing diagnostics and therefore could serve useful in billing
discrepancies, and provide for a better estimation of the time-span discrepancies, and provide for a better estimation of the time-span
skipping to change at page 19, line 47 skipping to change at page 18, line 47
| +---------+ | | +---------+ |
+-------------------------------+ +-------------------------------+
Figure 4: Fully enabled framework Figure 4: Fully enabled framework
Figure 4 Figure 4
In the fully enabled model the NSP also includes a component that In the fully enabled model the NSP also includes a component that
provides network resource management (e.g. QoS management), as provides network resource management (e.g. QoS management), as
described in section 3.4, "Network Resource Management by NSP". In described in section 3.4, "Network Resource Management by NSP". In
the fully enabled model (Figure 3) resource management and admission the fully enabled model (Figure 4) resource management and admission
control is provided by MACF (Multicast Admission Control Function). control is provided by MACF (Multicast Admission Control Function).
This means that, before replying to the user's multicast request, the This means that, before replying to the user's multicast request, the
mAAA queries the MACF for a network resource access decision over the mAAA queries the MACF for a network resource access decision over the
interface IFd. The MACF is responsible for allocating network interface IFd. The MACF is responsible for allocating network
resources for forwarding multicast traffic. MACF also receives Leave resources for forwarding multicast traffic. MACF also receives Leave
information from NAS so that MACF releases corresponding reserved information from NAS so that MACF releases corresponding reserved
resources. resources.
5.3. Modularity of the framework 5.3. Modularity of the framework
In the interest of flexibility, this framework is modular so that it In the interest of flexibility, this framework is modular so that it
is possible that partially enabled versions of the models are is possible that partially enabled versions of the models are
supported. A AAA-enabled version provides AAA functionality without supported. A AAA-enabled version provides AAA functionality without
Network Resource management. A Network-Resource-Management-enabled Network Resource management. A Network-Resource-Management-enabled
(QoS-enabled) version provides Network Resource management without (QoS-enabled) version provides Network Resource management without
AAA functionality. Similarly, the possibility of one or more layers AAA functionality. Similarly, the possibility of one or more layers
of transit provision between an NSP and CP is in the interest of of transit provision between an NSP and CP is in the interest of
modularity and extendibility. modularity and extendibility.
6. IANA Considerations 6. Acknowledgments
The authors of this draft would like to express their appreciation to
Susheela Vaidya of Cisco Systms whose contributions to the
"Requirements for Multicast AAA coordinated between Content
Provider(s) and Network Service Provider(s)"
[I-D.ietf-mboned-maccnt-req] largely influenced this draft; Pekka
Savola of Netcore Ltd.; Daniel Alvarez, and Toerless Eckert of Cisco
Systems; Sam Sambasivan of AT&T; Sanjay Wadhwa, Greg Shepherd, and
Leonard Giuliano of Juniper; Tom Anschutz and Steven Wright of
BellSouth; Nicolai Leymann of T-Systems; Bill Atwood of Concordia
University; Carlos Garcia Braschi of Telefonica Empresas; Mark Altom,
Andy Huang, Tom Imburgia, Han Nguyen, Doug Nortz of ATT Labs;
Marshall Eubanks in his role as mboned WG chair; Ron Bonica in his
role as Director as the Operations and Management Area; Stephen Rife
of Digital Garage and David Meyer in his former role as mboned WG
chair as well as their thanks to the participants of the MBONED WG in
general.
Funding for the RFC Editor function is currently provided by the
Internet Society.
7. IANA Considerations
This memo does not raise any IANA consideration issues. This memo does not raise any IANA consideration issues.
7. Security Considerations 8. Security Considerations
The user information related to authentication with the CP and the The user information related to authentication with the CP and the
information related to user accounting shared between the NSP and the information related to user accounting shared between the NSP and the
CP must be protected in some way. Otherwise, this memo does not CP must be protected in some way. Otherwise, this memo does not
raise any new security issues which are not already addressed by the raise any new security issues which are not already addressed by the
original protocols. Enhancement of multicast access control original protocols. Enhancement of multicast access control
capabilities should enhance security performance. capabilities should enhance security performance.
8. Conclusion 9. Conclusion
This memo provides a generalized framework for solution standards to This memo provides a generalized framework for solution standards to
meet the requirements. Further work should be done to specify the meet the requirements. Further work should be done to specify the
interfaces between the user and NSP, NAS and mAAA, mAAA and MACF and interfaces between the user and NSP, NAS and mAAA, mAAA and MACF and
NSP-mAAA and CP-AAA (presented in 5.2.) NSP-mAAA and CP-AAA (presented in 5.2.)
9. Normative References 10. Normative References
[I-D.ietf-ancp-framework] [I-D.ietf-ancp-framework]
Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S. Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S.
Wadhwa, "Framework and Requirements for an Access Node Wadhwa, "Framework and Requirements for an Access Node
Control Mechanism in Broadband Multi-Service Networks", Control Mechanism in Broadband Multi-Service Networks",
draft-ietf-ancp-framework-11 (work in progress), draft-ietf-ancp-framework-11 (work in progress),
July 2009. July 2009.
[I-D.ietf-mboned-maccnt-req] [I-D.ietf-mboned-maccnt-req]
Hayashi, T., He, H., Satou, H., Ohta, H., and S. Vaidya, Hayashi, T., He, H., Satou, H., Ohta, H., and S. Vaidya,
"Requirements for Multicast AAA coordinated between "Requirements for Multicast AAA coordinated between
Content Provider(s) and Network Service Provider(s)", Content Provider(s) and Network Service Provider(s)",
draft-ietf-mboned-maccnt-req-08 (work in progress), draft-ietf-mboned-maccnt-req-08 (work in progress),
July 2009. July 2009.
Authors' Addresses Authors' Addresses
Tsunemasa Hayashi
NTT Network Innovation Laboratories
1-1 Hikarino'oka
Yokosuka-shi, Kanagawa 239-0847
Japan
Phone: +81 46 859 8790
Email: hayashi.tsunemasa@lab.ntt.co.jp
Haixiang He
Nortel
600 Technology Park Drive
Billerica, MA 01801
USA
Phone: +1 978 288 7482
Email: haixiang@nortel.com
Hiroaki Satou Hiroaki Satou
NTT Network Service Systems Laboratories Nippon Telegraph and Telephone Corporation
3-9-11 Midoricho 3-9-11 Midoricho
Musashino-shi, Tokyo 180-8585 Musashino-shi, Tokyo 180-8585
Japan Japan
Phone: +81 422 59 4683 Phone: +81 422 59 4683
Email: satou.hiroaki@lab.ntt.co.jp Email: satou.hiroaki@lab.ntt.co.jp
Hiroshi Ohta Hiroshi Ohta
NTT Network Service Systems Laboratories Nippon Telegraph and Telephone Corporation
3-9-11 Midoricho 3-9-11 Midoricho
Musashino-shi, Tokyo 180-8585 Musashino-shi, Tokyo 180-8585
Japan Japan
Phone: +81 422 59 3617 Phone: +81 422 59 3617
Email: ohta.hiroshi@lab.ntt.co.jp Email: ohta.hiroshi@lab.ntt.co.jp
Tsunemasa Hayashi
Nippon Telegraph and Telephone Corporation
1-1 Hikarino'oka
Yokosuka-shi, Kanagawa 239-0847
Japan
Phone: +81 46 859 8790
Email: hayashi.tsunemasa@lab.ntt.co.jp
Christian Jacquenet Christian Jacquenet
France Telecom France Telecom
3, avenue Francois Chateau 3, avenue Francois Chateau
CS 36901, Rennes Cedex 95134 CS 36901, Rennes Cedex 95134
France France
Phone: +33 2 99 87 61 92 Phone: +33 2 99 87 61 92
Email: christian.jacquenet@orange-ftgroup.com Email: christian.jacquenet@orange-ftgroup.com
Haixiang He
Nortel
600 Technology Park Drive
Billerica, MA 01801
USA
Phone: +1 978 288 7482
Email: haixiang@nortel.com
Copyright and License Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
 End of changes. 23 change blocks. 
104 lines changed or deleted 111 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/