draft-ietf-mboned-multiaaa-framework-02.txt   draft-ietf-mboned-multiaaa-framework-03.txt 
Hiroaki Satou, NTT
Internet Draft Hiroshi Ohta, NTT
Expires: April 26, 2007 Christian Jacquenet, France Telecom
Tsunemasa Hayashi, NTT
Haixiang He, Nortel Networks
October 23, 2006 MBONED WG Hiroaki Satou, NTT
Internet-Draft Hiroshi Ohta, NTT
Proposed Status: Informational Christian Jacquenet, France Telecom
Expires: September 2, 2007 Tsunemasa Hayashi, NTT
Haixiang He, Nortel Networks
March 4, 2007
AAA Framework for Multicasting AAA Framework for Multicasting
<draft-ietf-mboned-multiaaa-framework-02.txt> <draft-ietf-mboned-multiaaa-framework-03.txt>
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
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 Internet-Drafts are draft documents valid for a maximum of six months
months and may be updated, replaced, or obsoleted by other documents and may be updated, replaced, or obsoleted by other documents at any
at any time. It is inappropriate to use Internet-Drafts as time. It is inappropriate to use Internet-Drafts as reference
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 April 26, 2007. This Internet-Draft will expire on September 2, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006) Copyright (C) The IETF Trust (2007).
Abstract Abstract
IP multicast-based services, such as TV broadcasting or IP multicast-based services, such as TV broadcasting or
videoconferencing raise the issue of making sure that potential videoconferencing raise the issue of making sure that potential
customers are fully entitled to access the corresponding contents. customers are fully entitled to access the corresponding
There is indeed a need for service and content providers to identify contents. There is indeed a need for service and content
(if not authenticate, especially within the context of enforcing providers to identify (if not authenticate, especially within the
electronic payment schemes) and to invoice such customers in a context of enforcing electronic payment schemes) and to invoice
reliable and efficient manner. This memo describes the framework for such customers in a reliable and efficient manner. This memo
specifying the Authorization, Authentication and Accounting (AAA) describes the framework for specifying the Authorization,
capabilities that could be activated within the context of the Authentication and Accounting (AAA) capabilities that could be
deployment and the operation of IP multicast-based services. This activated within the context of the deployment and the operation
framework addresses the requirements presented in draft-ietf-mboned- of IP multicast-based services. This framework addresses the
maccnt-req-04.txt, "Requirements for Accounting, Authentication and requirements presented in draft-ietf-mboned-maccnt-req-04.txt,
Authorization in Well Managed IP Multicasting Services". "Requirements for Accounting, Authentication and Authorization in
Well Managed IP Multicasting Services".
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 1-to-n (case of TV broadcasting schemes of any kind, such as 1-to-n (case of TV broadcasting
services for example) or n-to-p (case of videoconferencing services, services for example) or n-to-p (case of videoconferencing services,
for example). for example).
In these environments, IP multicast provides a better resource In these environments, IP multicast provides a better resource
optimization than using a unicast transmission scheme, where data optimization than using a unicast transmission scheme, where data
skipping to change at page 4, line 29 skipping to change at page 4, line 41
Authorization: The set of capabilities that need to be activated to Authorization: The set of capabilities that need to be activated to
make sure a given requesting customer is (1) what he claims to be make sure a given requesting customer is (1) what he claims to be
(identification purposes), and (2) is fully entitled to access a set (identification purposes), and (2) is fully entitled to access a set
of services (authentication purposes). of services (authentication purposes).
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 identified by a network ID such as MAC address or IP receiver may be identified by a network ID such as MAC address or IP
address. address.
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) Note: The definition of a receiver (device) and a user (human)
should not be confused. should not be confused.
2.2 Abbreviations 2.2 Abbreviations
For the purpose of this draft the following abbreviations apply: For the purpose of this draft the following abbreviations apply:
ACL: Access Control List ACL: Access Control List
CDN: Content Delivery Network CDN: Content Delivery Network
CDS: Content Delivery Services CDS: Content Delivery Services
CP: Content Provider CP: Content Provider
NSP: Network Service Provider NSP: Network Service Provider
TP: Transit Provider TP: Transit Provider
skipping to change at page 5, line 14 skipping to change at page 6, line 14
3. Common use models and network architecture implications 3. Common use models and network architecture implications
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
multicasting system such as 1) content serving, 2) the multicasting system such as 1) content serving, 2) the
infrastructure to multicast it, 3) network and content access infrastructure to multicast it, 3) network and content access
control mechanisms. In many cases however the content provision and control mechanisms. In many cases however the content provision and
network provision roles are divided between separate entities. The network provision roles are divided between separate entities. The
MACCNT-REQ-draft provides more detail of the multiple versus single MACCNT-REQ-draft provides more detail of the multiple versus single
entity CDS network model. entity CDS network models.
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 multicasting structure and the entity responsible for content
serving are the same. Indeed because the infrastructure for serving are the same. Indeed because the infrastructure for
multicasting is expensive and many content holders are not likely to multicasting is expensive and many content holders are not likely to
be competent at building and maintaining complicated infrastructures be competent at building and maintaining complicated infrastructures
necessary for multicasting, many content holders would prefer to necessary for multicasting, many content holders would prefer to
purchase transport and management services from a network service purchase transport and management services from a network service
provider and thus share the infrastructure costs with other content provider and thus share the infrastructure costs with other content
holders. holders.
skipping to change at page 7, line 17 skipping to change at page 8, line 17
the AAA messages from the CP whether the user is eligible to receive the AAA messages from the CP whether the user is eligible to receive
content (authentication by proxy), and the NSPs relevant AAA server content (authentication by proxy), and the NSPs relevant AAA server
will make the final decision of whether the connection can be will make the final decision of whether the connection can be
established. When the NSP cannot or decides not to multicast to established. When the NSP cannot or decides not to multicast to
users, the NSP is responsible for notifying the users of the reason. users, the NSP is responsible for notifying the users of the reason.
4.2 Multiple User IDs 4.2 Multiple User IDs
Users may hold multiple user IDs: IDs which have been separately Users may hold multiple user IDs: IDs which have been separately
assigned for each subscription they may have for various NSPs and assigned for each subscription they may have for various NSPs and
CPs. When the user wants to access content or otherwise use the CPs. The NSPs and CPs control the user IDs for their respective
network, the user registers the corresponding user ID with a request domains. The user IDs are only meaningful in the context of each
for content, etc: web authentication is one possible method. domain.
Terminal portability can be realized if the NSP authenticates a user When the user wants to access content, the user registers the
using a user ID. This allows the user to access the content from corresponding user ID (including its CP domain information) with a
various network access points. request for content, etc: web authentication is one possible method.
Each CP may identify users by the user IDs that it has issued to Each CP may identify users by the user IDs that it has issued to
them. them.
Terminal portability can be realized if the NSP authenticates a user
using a NSP-domained user ID. This allows the user to access the
content from various network access points.
The NSP and CP do not need to know the corresponding user id for the The NSP and CP do not need to know the corresponding user id for the
same user in the other provider's domain, and it is not necessary same user in the other provider's domain, and it is not necessary
that there is a one to one relationship. It is quite possible for that there is a one to one relationship. It is quite possible for
one person to hold multiple user ids for the same provider. one person to hold multiple user ids for the same provider.
The actual mapping rules for NSPs and CPs to map user IDs with the
IDs in other provider domains is a matter for the providers. A
solution should provide an API between the providers to flexibly
support various mapping methods.
4.3 Accounting 4.3 Accounting
MACCNT-REQ-draft defines requirements for Accounting and Billing. MACCNT-REQ-draft defines requirements for Accounting and Billing.
These include the requirement for the NSP to log user behavior such These include the requirement for the NSP to log user behavior such
as the join action and the leave action, as well as the result of as the join action and the leave action, as well as the result of
the access-control decision. (MACCNT-REQ-draft, 4.5) MACCNT-REQ- the access-control decision. (MACCNT-REQ-draft, 4.5) MACCNT-REQ-
draft also specifies that there should be a standardized format for draft also specifies that there should be a standardized format for
sharing with the CP the user behavior and content reception sharing with the CP the user behavior and content reception
information which the NSP is logging.(MACCNT-REQ-draft, 4.5.1) information which the NSP is logging.(MACCNT-REQ-draft, 4.5.1)
In order to provide the granularity of user-behavior and actual In order to provide the granularity of user-behavior and actual
content reception information as specified in MACCNT-REQ-draft, the content reception information as specified in MACCNT-REQ-draft, the
NSP should not manage multicast states on a subnet basis, but on a NSP should not manage multicast states on a subnet basis, but on a
user basis (see in MACCNT-REQ-draft, 4.1 "User identification") user basis (see in MACCNT-REQ-draft, 4.1 "User identification")
because the NSP needs to be able to notify the CP of a user's start because the NSP needs to be able to notify the CP of a user's start
and stop times for accounting purposes. This means that the NSP and stop times for accounting purposes. This means that the NSP
sends to the CP AAA an indication for Join and Leave on a user basis. sends to the CP AAA an indication for Join and Leave on a user
basis.
This framework specifies an accounting API provided by the NSP and This framework specifies an accounting API provided by the NSP and
accessed by the CP to allow for sharing user-behavior and content- accessed by the CP to allow for sharing user-behavior and content-
reception information between the NSP AAA and CP AAA. This reception information between the NSP AAA and CP AAA. This
accounting API should be configurable to allow the CP to request accounting API should be configurable to allow the CP to request
only the logging information it actually requires. Such an API only the logging information it actually requires. Such an API
would allow for realtime accounting information sharing by the NSP would allow for realtime accounting information sharing by the NSP
to the CP. When logging information is shared through the accounting to the CP. When logging information is shared through the accounting
API, it is important that the CP be able to match the user as API, it is important that the CP be able to match the user as
described in the database operated by the NSP to the user as described in the database operated by the NSP to the user as
skipping to change at page 9, line 44 skipping to change at page 11, line 7
5.1 Basic Connection Model 5.1 Basic Connection Model
+-------------+ +-------------+
| user | | user |
| | | |
+-------------+ +-------------+
^ Access & Resource ^ Access & Resource
| Request | Request
v v
+-------------+ +-------------+
| NSP | | NSP= NAP |
| | | |
+-------------+ +-------------+
^ Access ^ Access
| Request | Request
v v
+-------------+ +-------------+
| CP | | CP |
| | | |
+-------------+ +-------------+
First a user that requests content sends an Access request to an NSP In this case the NSP is the sole entity providing Network Service
which then forwards it on to the appropriate CP for Authentication Provision including Network Access Provision to the User. First a
and Authorization purposes. The CP responds with either "success" or user that requests content sends an Access request to an NSP which
then forwards it on to the appropriate CP for Authentication and
Authorization purposes. The CP responds with either "success" or
"failure". If "success", the NSP may forward a success response and "failure". If "success", the NSP may forward a success response and
stream multicast data to the user. stream multicast data to the user.
In this model the user selects the NSP to which to send its content In this model the user selects the NSP to which to send its content
request. Based on this request the NSP selects an appropriate CP to request. Based on this request the NSP selects an appropriate CP to
which it forwards the request. The CP responds to the NSP's request: which it forwards the request. The CP responds to the NSP's request:
it may not respond to another NSP in regards to the request. it may not respond to another NSP in regards to the request.
In this model, as described in section 3.1, the relationship between In this model, as described in section 3.1, the relationship between
NSP and CP can be 1:1, 1:N or M:N. Users may connect to multiple NSP and CP can be 1:1, 1:N or M:N. Users may connect to multiple
networks, and networks have multiple users. networks, and networks have multiple users.
5.2 Transit Provision 5.2 Transit Provision
The diagram below shows that a Transit Provider(hereafter, TP) may The diagram below shows that Network Service Provision may include
relay requests between NSPs and CPs. both Network Access Provision to the User and also Transit Provision
(request relay) between the Network Access Provider (NAP) and the CP.
Transit Provision is the responsibility of the NSP which may or may
not contract out this service to a separate NSP that acts as the
Transit Provider. The existence of the Transit Provider is
transparent to the user.
+-------------+ +-------------+
| user | | user |
| | | |
+-------------+ +-------------+
^ Access & Resource ^ Access & Resource
| Request | Request
v v
+-------------+ +- - - - - - - - - - - - - - +
| NSP | |+----------------+
| | | Network Access | |
+-------------+ || Provision | Network Service
^ Access & Resource +----------------+ | Provision
| Request | ^ Access & Resource
v | Request |
+-------------+ | v
| TP | +-------------+ |
| | || Transit |
+-------------+ | Provision | |
|+-------------+
+- - - - - - - - - - - - - - +
^ Access ^ Access
| Request | Request
v v
+-------------+ +-------------+
| CP | | CP |
| | | |
+-------------+ +-------------+
For the sake of simplification the above diagram shows a 1-1 For the sake of simplification the above diagram shows a 1-1
relationship between an NSP and a TP. However it is also possible relationship between an NAP and a TP. However it is also possible
for a single NSP to connect to multiple TPs, and a single TP to for a single NAP to connect to multiple TPs, and a single TP to
multiple NSPs. multiple NAPs.
A single TP may connect to one or more CPs. Similarly just as a A single TP may connect to one or more CPs. Similarly just as a
single CP may connect to multiple NSPs (as described in the general single CP may connect to multiple NAPs (as described in the general
high-level framework, section 3.1), a single CP may connect to one high-level framework, section 3.1), a single CP may connect to one
or more TPs. or more TPs.
A solution will include a mechanism through which the NSPs know A solution will include a mechanism through which the NAPs know
which TP(s) are to be used to communicate with which CP(s), and CPs which TP(s) are to be used to communicate with which CP(s), and CPs
know which TP(s) to use for which NSP(s). When a TP receives an know which TP(s) to use for which NAP(s). When a TP receives an
access or resource request from an NSP or CP, it must relay the access or resource request from an NAP or CP, it must relay the
request to the correct CP or NSP, respectively. Minimally, this request to the correct CP or NSP, respectively. Minimally, this
means that it must reconstruct the request with translated address means that it must reconstruct the request with translated address
information. In this model therefore a TP must understand the information. In this model therefore a TP must understand the
format and meaning of the requests. format and meaning of the requests.
There may be multiple TPs between a NSP and CP so that a TP is There may be multiple TPs between a NAP and CP so that a TP is
actually receiving from and/or sending requests to another TP and actually receiving from and/or sending requests to another TP and
not directly from/to a NSP or CP. not directly from/to a NAP or CP.
5.3 Transit with Tunnels 5.3 Transit with Tunnels
In addition to the above model of request relaying, a TP may In addition to the above model of request relaying, a TP may
communicate requests through tunneling based on the contract between communicate requests through tunneling based on the contract between
the TP and the NSP and/or between the TP and the CP. So in this the TP and the NAP and/or between the TP and the CP. So in this
case the TP will not directly need to process the contents of the case the TP will not directly need to process the contents of the
access and resource request (such as, header information), but access and resource request (such as, header information), but
instead pass the request directly to the correct NSP or CP, using a instead pass the request directly to the correct NSP or CP, using a
separate protocol to wrap the original requests. separate protocol to wrap the original requests.
Below is a diagram, representing how a TP can provide tunneling Below is a diagram, representing how a TP can provide tunneling
between NSP(s) and CP(s). between NAP(s) and CP(s).
+-----------------+ +-----------------+
| user | | user |
| | | |
+-----------------+ +-----------------+
^ Access & Resource ^ Access & Resource
| Request | Request
v v
+ - - - - - - - - - - +
+------------------+ +------------------+
| NSP | || NAP | |
| | | |
+------------------+ |+------------------+ | Network
|^| |^|
| |:| | Service
|:| |:|
|:| |+-|:|--------------+ | Provision
+-|:|--------------+
| |:| TP | | |:| TP |
| |:| | || |:| | |
+-|:|--------------+ +-|:|--------------+
|:| + -|:|- - - - - - - - +
|:| Tunnel |:| Tunnel
|:| |:|
|V| |V|
+------------------+ +------------------+
| CP | | CP |
| | | |
+------------------+ +------------------+
In this model too, the relationship between NSP and TP and between In this model too, the relationship between NAP and TP and between
transit provider and CP can be 1:1, 1:N or M:N. TP and CP can be 1:1, 1:N or M:N.
5.4 Constituent Logical Functional Components of the fully enabled AAA 5.4 Constituent Logical Functional Components of the fully enabled AAA
Framework Framework
Section 3.1 introduces the high-level AAA framework for multicasting. Section 3.1 introduces the high-level AAA framework for multicasting.
Below is a diagram of a fully enabled multicasting network with AAA, Below is a diagram of a fully enabled multicasting network with AAA,
including the logical components within the various entities. including the logical components within the various entities.
+-------------------------------+ +-------------------------------+
| user | | user |
skipping to change at page 14, line 20 skipping to change at page 16, line 20
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. IANA considerations
This memo does not raise any IANA consideration issues. This memo does not raise any IANA consideration issues.
7. Security considerations 7. Security considerations
Refer to section 3.3. Also the user information related to Refer to section 3.3. Also the user information related to
authentication with the CP must be protected in some way. Otherwise, authentication with the CP must be protected in some way.
this memo does not raise any new security issues which are not Otherwise, this memo does not raise any new security issues which
already addressed by the original protocols. Enhancement of are not already addressed by the original protocols. Enhancement of
multicast access control capabilities should enhance security multicast access control capabilities should enhance security
performance. performance.
8. Conclusion 8. Conclusion
This memo provides a generalized framework for solution standards to This memo provides a generalized framework for solution standards to
meet the requirements presented in MACCNT-REQ-draft. Further work meet the requirements presented in MACCNT-REQ-draft. Further work
should be done to break down the content provider and network should be done to break down the content provider and network
service provider entities into their functional objects such as edge service provider entities into their functional objects such as edge
devices, AAA servers, etc. devices, AAA servers, etc.
skipping to change at page 16, line 5 skipping to change at page 18, line 5
600 Technology Park Drive 600 Technology Park Drive
Billerica, MA 01801, USA Billerica, MA 01801, USA
Phone: +1 978 288 7482 Phone: +1 978 288 7482
Email: haixiang@nortel.com Email: haixiang@nortel.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 Intellectual Property Statement
Copyright (C) The Internet Society (2006).
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 The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed Intellectual Property Rights or other rights that might be claimed to
to pertain to the implementation or use of the technology described pertain to the implementation or use of the technology described in
in this document or the extent to which any license under such this document or the extent to which any license under such rights
rights might or might not be available; nor does it represent that might or might not be available; nor does it represent that it has
it has made any independent effort to identify any such rights. made any independent effort to identify any such rights. Information
Information on the procedures with respect to rights in RFC on the procedures with respect to rights in RFC documents can be
documents can be found in BCP 78 and BCP 79. 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 attempt made to obtain a general license or permission for the use of
of such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository specification can be obtained from the IETF on-line IPR repository at
at http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at
ipr@ietf.org. ietf-ipr@ietf.org.
Expiration Disclaimer of Validity
This Internet-Draft will expire on April 26, 2007. 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, THE IETF TRUST 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.
Acknowledgement Copyright Statement
Copyright (C) The IETF Trust (2007). 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.
Acknowledgment
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. 44 change blocks. 
107 lines changed or deleted 123 lines changed or added

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