--- 1/draft-ietf-mboned-multiaaa-framework-02.txt 2007-03-17 21:12:08.000000000 +0100 +++ 2/draft-ietf-mboned-multiaaa-framework-03.txt 2007-03-17 21:12:08.000000000 +0100 @@ -1,64 +1,65 @@ - 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 - + Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. - Internet-Drafts are draft documents valid for a maximum of six - months and may be updated, replaced, or obsoleted by other documents - at any time. It is inappropriate to use Internet-Drafts as - reference material or to cite them other than as "work in progress." + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on April 26, 2007. + This Internet-Draft will expire on September 2, 2007. Copyright Notice - Copyright (C) The Internet Society (2006) + Copyright (C) The IETF Trust (2007). 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 - (if not authenticate, especially within the context of enforcing - electronic payment schemes) and to invoice such customers in a - reliable and efficient manner. 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 draft-ietf-mboned- - maccnt-req-04.txt, "Requirements for Accounting, Authentication and - Authorization in Well Managed IP Multicasting Services". + customers are fully entitled to access the corresponding + contents. There is indeed a need for service and content + providers to identify (if not authenticate, especially within the + context of enforcing electronic payment schemes) and to invoice + such customers in a reliable and efficient manner. 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 draft-ietf-mboned-maccnt-req-04.txt, + "Requirements for Accounting, Authentication and Authorization in + Well Managed IP Multicasting Services". 1. Introduction 1.1 Purpose and Background IP multicasting is designed to serve cases of group communication schemes of any kind, such as 1-to-n (case of TV broadcasting services for example) or n-to-p (case of videoconferencing services, for example). In these environments, IP multicast provides a better resource optimization than using a unicast transmission scheme, where data @@ -134,31 +135,31 @@ Authorization: The set of capabilities that need to be activated to make sure a given requesting customer is (1) what he claims to be (identification purposes), and (2) is fully entitled to access a set of services (authentication purposes). 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 address. 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 not be confused. 2.2 Abbreviations For the purpose of this draft the following abbreviations apply: ACL: Access Control List - CDN: Content Delivery Network CDS: Content Delivery Services CP: Content Provider NSP: Network Service Provider TP: Transit Provider @@ -164,21 +165,21 @@ 3. Common use models and network architecture implications In some cases a single entity may design and be responsible for a system that covers the various common high-level requirements of a multicasting system such as 1) content serving, 2) the infrastructure to multicast it, 3) network and content access control mechanisms. In many cases however the content provision and network provision roles are divided between separate entities. The 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 multicasting structure and the entity responsible for content serving are the same. Indeed because the infrastructure for multicasting is expensive and many content holders are not likely to be competent at building and maintaining complicated infrastructures necessary for multicasting, many content holders would prefer to purchase transport and management services from a network service provider and thus share the infrastructure costs with other content holders. @@ -262,53 +263,62 @@ the AAA messages from the CP whether the user is eligible to receive content (authentication by proxy), and the NSPs relevant AAA server will make the final decision of whether the connection can be established. When the NSP cannot or decides not to multicast to users, the NSP is responsible for notifying the users of the reason. 4.2 Multiple User IDs Users may hold multiple user IDs: IDs which have been separately assigned for each subscription they may have for various NSPs and - CPs. When the user wants to access content or otherwise use the - network, the user registers the corresponding user ID with a request - for content, etc: web authentication is one possible method. + CPs. The NSPs and CPs control the user IDs for their respective + domains. The user IDs are only meaningful in the context of each + domain. - Terminal portability can be realized if the NSP authenticates a user - using a user ID. This allows the user to access the content from - various network access points. + When the user wants to access content, the user registers the + corresponding user ID (including its CP domain information) with a + request for content, etc: web authentication is one possible method. Each CP may identify users by the user IDs that it has issued to 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 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 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 MACCNT-REQ-draft defines requirements for Accounting and Billing. 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 the access-control decision. (MACCNT-REQ-draft, 4.5) MACCNT-REQ- draft also specifies that there should be a standardized format for sharing with the CP the user behavior and content reception information which the NSP is logging.(MACCNT-REQ-draft, 4.5.1) - In order to provide the granularity of user-behavior and actual content reception information as specified in MACCNT-REQ-draft, the NSP should not manage multicast states on a subnet basis, but on a 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 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 accessed by the CP to allow for sharing user-behavior and content- reception information between the NSP AAA and CP AAA. This accounting API should be configurable to allow the CP to request only the logging information it actually requires. Such an API would allow for realtime accounting information sharing by the NSP 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 described in the database operated by the NSP to the user as @@ -385,142 +395,152 @@ 5.1 Basic Connection Model +-------------+ | user | | | +-------------+ ^ Access & Resource | Request v +-------------+ - | NSP | + | NSP= NAP | | | +-------------+ ^ Access | Request v +-------------+ | CP | | | +-------------+ - First a 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 + In this case the NSP is the sole entity providing Network Service + Provision including Network Access Provision to the User. First a + 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 stream multicast data to the user. 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 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. 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 networks, and networks have multiple users. 5.2 Transit Provision - The diagram below shows that a Transit Provider(hereafter, TP) may - relay requests between NSPs and CPs. + The diagram below shows that Network Service Provision may include + 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 | | | +-------------+ ^ Access & Resource | Request v - +-------------+ - | NSP | - | | - +-------------+ - ^ Access & Resource - | Request - v - +-------------+ - | TP | - | | - +-------------+ + +- - - - - - - - - - - - - - + + |+----------------+ + | Network Access | | + || Provision | Network Service + +----------------+ | Provision + | ^ Access & Resource + | Request | + | v + +-------------+ | + || Transit | + | Provision | | + |+-------------+ + +- - - - - - - - - - - - - - + ^ Access | Request v +-------------+ | CP | | | +-------------+ For the sake of simplification the above diagram shows a 1-1 - relationship between an NSP and a TP. However it is also possible - for a single NSP to connect to multiple TPs, and a single TP to - multiple NSPs. + relationship between an NAP and a TP. However it is also possible + for a single NAP to connect to multiple TPs, and a single TP to + multiple NAPs. 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 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 - know which TP(s) to use for which NSP(s). When a TP receives an - access or resource request from an NSP or CP, it must relay the + know which TP(s) to use for which NAP(s). When a TP receives an + access or resource request from an NAP or CP, it must relay the request to the correct CP or NSP, respectively. Minimally, this means that it must reconstruct the request with translated address information. In this model therefore a TP must understand the 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 - not directly from/to a NSP or CP. + not directly from/to a NAP or CP. 5.3 Transit with Tunnels In addition to the above model of request relaying, a TP may 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 access and resource request (such as, header information), but instead pass the request directly to the correct NSP or CP, using a separate protocol to wrap the original requests. Below is a diagram, representing how a TP can provide tunneling - between NSP(s) and CP(s). + between NAP(s) and CP(s). +-----------------+ | user | | | +-----------------+ ^ Access & Resource | Request v + + - - - - - - - - - - + +------------------+ - | NSP | + || NAP | | | | - +------------------+ + |+------------------+ | Network |^| + | |:| | Service |:| - |:| - +-|:|--------------+ + |+-|:|--------------+ | Provision | |:| TP | - | |:| | + || |:| | | +-|:|--------------+ - |:| + + -|:|- - - - - - - - + |:| Tunnel |:| |V| +------------------+ | CP | | | +------------------+ - In this model too, the relationship between NSP and TP and between - transit provider and CP can be 1:1, 1:N or M:N. + In this model too, the relationship between NAP and TP and between + TP and CP can be 1:1, 1:N or M:N. 5.4 Constituent Logical Functional Components of the fully enabled AAA Framework Section 3.1 introduces the high-level AAA framework for multicasting. Below is a diagram of a fully enabled multicasting network with AAA, including the logical components within the various entities. +-------------------------------+ | user | @@ -571,23 +591,23 @@ of transit provision between an NSP and CP is in the interest of modularity and extendibility. 6. IANA considerations This memo does not raise any IANA consideration issues. 7. Security considerations Refer to section 3.3. Also the user information related to - authentication with the CP must be protected in some way. Otherwise, - this memo does not raise any new security issues which are not - already addressed by the original protocols. Enhancement of + authentication with the CP must be protected in some way. + Otherwise, this memo does not raise any new security issues which + are not already addressed by the original protocols. Enhancement of multicast access control capabilities should enhance security performance. 8. Conclusion This memo provides a generalized framework for solution standards to meet the requirements presented in MACCNT-REQ-draft. Further work should be done to break down the content provider and network service provider entities into their functional objects such as edge devices, AAA servers, etc. @@ -630,58 +650,54 @@ 600 Technology Park Drive Billerica, MA 01801, USA Phone: +1 978 288 7482 Email: haixiang@nortel.com Comments Comments are solicited and should be addressed to the mboned working group's mailing list at mboned@lists.uoregon.edu_and/or the authors. -Full Copyright 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 +Intellectual Property Statement The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed - to pertain to the implementation or use of the technology described - in this document or the extent to which any license under such - rights might or might not be available; nor does it represent that - it has made any independent effort to identify any such rights. - Information on the procedures with respect to rights in RFC - documents can be found in BCP 78 and BCP 79. + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use - of such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository - at http://www.ietf.org/ipr. + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at ietf- - ipr@ietf.org. + this standard. Please address the information to the IETF at + 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 Internet Society.