idnits 2.17.1 draft-ietf-mboned-multiaaa-framework-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 533. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 544. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 551. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 557. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 2006) is 6579 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-10) exists of draft-ietf-mboned-maccnt-req-04 ** Downref: Normative reference to an Informational draft: draft-ietf-mboned-maccnt-req (ref. '1') == Outdated reference: A later version (-03) exists of draft-ietf-mboned-rac-issues-02 -- Possible downref: Normative reference to a draft: ref. '2' Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft AAA Framework for Multicasting April 2006 4 Hiroaki Satou, NTT 5 Internet Draft Hiroshi Ohta, NTT 6 Expires: October 6, 2006 Tsunemasa Hayashi, NTT 7 Haixiang He, Nortel Networks 9 April 4, 2006 11 AAA Framework for Multicasting 12 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six 27 months and may be updated, replaced, or obsoleted by other documents 28 at any time. It is inappropriate to use Internet-Drafts as 29 reference material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on October 6, 2006. 39 Copyright Notice 41 Copyright (C) The Internet Society (2006) 43 Abstract 44 This memo provides a generalized framework for solution standards to 45 meet the requirements presented in draft-ietf-mboned-maccnt-req- 46 04.txt, "Requirements for Accounting, Authentication and 47 Authorization in Well Managed IP Multicasting Services". In this 48 framework a user sends a request for multicast data to a network 49 service provider. The network service provider selects the 50 appropriate content provider to send the user's request. The 51 request is sent by the network service provider to the content 52 provider transparently in a way so that the network service provider 53 and content provider do not need to know the corresponding user id 54 for the same user in the other provider's domain. The content 55 provider then responds with an indication of "success" or "failure" 56 to the network provider and in the case of "success", the network 57 provider may delivery the requested data to the user. The network 58 service may base its decision to deliver such data to the user based 59 on its bandwidth management policy. The framework is designed to be 60 flexible and extendible, so it will be possible to implement 61 partially enabled versions as well as fully enabled versions of the 62 model. Also an additional entity may provide transit of requests 63 between network service providers and content providers, either 64 through relaying or tunneling. 66 1. Introduction 68 1.1 Purpose and Background 70 IP multicasting is designed to serve cases where a single source of 71 data content is to be concurrently streamed to multiple recipients. 73 In these types of cases, multicasting provides resource efficiencies 74 (both for the overall network and the content server) relative to 75 unicasting. These efficiencies are possible because of the 76 avoidance of unnecessary duplication of streams, video/audio 77 processing, etc. Multicasting also provides resource efficiencies 78 relative to IP broadcasting in that content data is only delivered 79 to end hosts which request it. 81 There are many real-life situations where IP multicasting is 82 selected as the technology used for concurrent content delivery of 83 identical content data to multiple end-hosts. "Requirements for 84 Accounting, Authentication and Authorization in Well Managed IP 85 Multicasting Services", (draft-ietf-mboned-maccnt-req-04.txt, 86 hereafter MACCNT-REQ-draft) describes the requirements in CDN 87 services using IP multicast[1]. "Issues Related to Receiver Access 88 Control in the Current Multicast Protocols" (draft-ietf-mboned-rac- 89 issues-02.txt, hereafter RAC-ISSUES-draft) discusses the 90 requirements and existing support for commercial, large-scale 91 content delivery[2]. The requirements are derived from: 92 - need for user tracking and billing capabilities 93 - need for network access control and/or content access control 94 to satisfy the requirements of the CP 95 - methods for sharing information between the network service 96 provider and content provider to make it possible to fulfill the 97 above two requirements. 99 Detailed requirements are presented in MACCNT-REQ-draft. These 100 requirements include mechanisms for recording end-user requests and 101 provider responses for content-delivery, sharing user information 102 (possibly anonymously depending on the trust model) between content 103 provider and network service provider, and protecting resources 104 through the prevention of network and content access by unauthorized 105 users, as well as other AAA related requirements. 107 The purpose of this memo is to provide a generalized framework for 108 solution standards to meet these requirements. This framework is to 109 provide a basis for defining protocols, but definition of the actual 110 protocols is outside of the scope of this memo. 112 2. Definitions and Abbreviations 114 2.1 Definitions 116 For the purposes of this memo the following definitions apply: 118 Accounting: actions for grasping each user's behavior, when she/he 119 starts/stops to receive a channel, which channel she/he receives, 120 etc. 122 Authentication: action for identifying a user as a genuine one. 124 Authorization: action for giving permission to access the content or 125 network to a user. 127 Receiver: an end-host or end-client which receives content. A 128 receiver may be distinguishable by a network ID such as MAC address 129 or IP address. 131 User: a human with a user account. A user may possibly use multiple 132 reception devices. Multiple users may use the same reception device. 134 Note: The definition of a receiver (device) and a user (human) 135 should not be confused. 137 2.2 Abbreviations 139 For the purposes of this draft the following abbreviations apply: 141 ACL: Access Control List 143 CDN: Content Delivery Network 145 CDS: Content Delivery Services 147 CP: Content Provider 149 NSP: Network Service Provider 151 TP: Transit Provider 153 3. Issues in multicasting related to commercial and large-scale 154 implementations 156 This section lists issues related to receiver access control in 157 current multicasting protocols which are especially important to 158 commercial, large-scale multicasting. More details concerning the 159 requirements related to these issues are provided in MACCNT-REQ- 160 draft. References to that memo are provided as applicable below. 162 3.1 Framework for multicast AAA allowing bandwidth Management 164 A general high-level framework can be represented as follows. 166 +------------------------------+ 167 | user | 168 | | 169 +------------------------------+ 170 | Access ^ Response 171 | Request | & Multicast Data 172 V | 173 +------------------------------+ 174 | NSP | 175 | | 176 +------------------------------+ 177 | Access ^ Response 178 | Request | (Success) 179 v | 180 +------------------------------+ 181 | CP | 182 | | 183 +------------------------------+ 185 For the sake of simplicity, the above diagram portrays a case where 186 there is a single NSP entity and a single CP entity. Under the 187 framework it is possible for there to be multiple CPs connected to 188 the same NSP. It is also possible for the same CP to be connected to 189 multiple NSP networks (e.g. network selection). In other words the 190 relationship of NSP:CP can be described as 1:1, 1:N or M:N. 191 Furthermore it is possible that the NSP and CP could be the same 192 entity. 194 Description of Roles: 196 The user selects a CP and a NSP when the user requests content. The 197 NSP may be automatically selected by a user terminal: e.g. a fixed 198 line NSP for STB or a mobile NSP for mobile phone. 200 The CP is responsible for Authentication and Authorization of users' 201 access to content that the CP manages. The CP hopes to collect 202 accounting information related to the access of their content. 204 The NSP is responsible for managing its network resources. The NSP 205 may perform admission control to protect bandwidth resource and 206 needs authorized information regarding user access for bandwidth 207 management. It is also responsible for confirming (authentication by 208 proxy) with the CP whether the user is eligible to receive content. 210 In addition to the three basic entities of user, NSP and CP, this 211 AAA framework for multicasting supports transit provision which 212 transfers multicast streams from the CP to the NSP. 214 3.2 Multiple User IDs 216 Users may be assigned separate user IDs for each subscription for 217 various NSPs and CPs. When the user wants to access content or 218 otherwise use the network, the user registers the corresponding user 219 ID with a request for content, etc: web authentication is one 220 possible method. 222 Terminal portability can be realized if the NSP authenticates a user 223 using a user ID. This allows the user to access the content from 224 various network access points. 226 Each CP may identify users by the user IDs that it has issued to 227 them. 229 The NSP and CP do not need to know the corresponding user id for the 230 same user in the other provider's domain, and it is not necessary 231 that there is a one to one relationship. It is quite possible for 232 one person to hold multiple user ids for the same provider. 234 3.3 Access Control and CP selection by NSP 236 When a NSP receives an access request from a user, it is necessary 237 for the NSP to determine to which CP the request is directed. It is 238 necessary for the NSP to ensure that it is not spoofed by an 239 inappropriate CP. 241 3.4 Network Resource Management by NSP 243 After authorizing a user request, the NSP may conduct admission 244 control based on its bandwidth management policy. For example, if 245 the NSP manages the shared bandwidth of access lines, the NSP might 246 calculate available bandwidth and necessary bandwidth, and based on 247 these calculations determine to accept or reject a user request. 249 3.5 Access Control and Distinguishing of Users by CP 251 The user ID and authentication information are forwarded 252 transparently by the NSP so that the CP can distinguish the user, as 253 well as authenticate and authorize the request. 255 3.6 Multicast Session Management for Accounting 257 The NSP should not manage multicast states on a subnet basis, but on 258 a user basis because the NSP needs to notify start and stop times 259 for accounting purposes. This means that the NSP sends an indication 260 for Join and Leave on a user basis. 262 4. Network Connection Model and Functional Components 264 Section 3.1 introduces the high-level AAA framework for multicasting. 265 This section provides more detail on the network connection model 266 and constituent functional components. 268 4.1 Basic Connection Model 270 +-------------+ 271 | user | 272 | | 273 +-------------+ 274 ^ Access & Resource 275 | Request 276 v 277 +-------------+ 278 | NSP | 279 | | 280 +-------------+ 281 ^ Access 282 | Request 283 v 284 +-------------+ 285 | CP | 286 | | 287 +-------------+ 289 First a user desiring authorization sends an Access request to an 290 NSP which then forwards it on to the appropriate CP for 291 Authentication and Authorization. The CP responds with either 292 "success" of "failure". If "success", the NSP may forward a success 293 response and stream multicast data to the user. 295 In this model the user selects the NSP to which to send its content 296 request. Based on this request the NSP selects an appropriate CP to 297 which it forwards the request. The CP responds to the NSP's request: 298 it may not respond to another NSP in regards to the request. 300 In this model, as described in section 3.1, the relationship between 301 NSP and CP can be 1:1, 1:N or M:N. Users may connect to multiple 302 networks, and networks have multiple users. 304 4.2 Transit Provision 306 The diagram below shows that a Transit Provider(hereafter, TP) may 307 relay requests between NSPs and CPs. 309 +-------------+ 310 | user | 311 | | 312 +-------------+ 313 ^ Access & Resource 314 | Request 315 v 316 +-------------+ 317 | NSP | 318 | | 319 +-------------+ 320 ^ Access & Resource 321 | Request 322 v 323 +-------------+ 324 | TP | 325 | | 326 +-------------+ 327 ^ Access 328 | Request 329 v 330 +-------------+ 331 | CP | 332 | | 333 +-------------+ 335 For the sake of simplification the above diagram shows a 1-1 336 relationship between an NSP and a TP. However it is also possible 337 for a single NSP to connect to multiple TPs, and a single TP to 338 multiple NSPs. 340 A single TP may connect to one or more CPs. Similarly just as a 341 single CP may connect to multiple NSPs (as described in the general 342 high-level framework, section 3.1), a single CP may connect to one 343 or more TPs. 345 A solution will include a mechanism through which the NSPs know 346 which TP(s) are to be used to communicate with which CP(s), and CPs 347 know which TP(s) to use for which NSP(s). When a TP receives an 348 access or resource request from an NSP or CP, it must relay the 349 request to the correct CP or NSP, respectively. Minimally, this 350 means that it must reconstruct the request with translated address 351 information. In this model therefore a TP must understand the 352 format and meaning of the requests. 354 There may be multiple TPs between a NSP and CP so that a TP is 355 actually receiving from and/or sending requests to another TP and 356 not directly from/to a NSP or CP. 358 4.3 Transit with Tunnels 360 In addition to the above model of request relaying, a TP may 361 communicate requests through tunneling based on the contract between 362 the TP and the NSP and/or between the TP and the CP. So in this 363 case the TP will not directly need to process the contents of the 364 access and resource request (such as, header information), but 365 instead pass the request directly to the correct NSP or CP, using a 366 separate protocol to wrap the original requests. 368 Below is a diagram, representing how a TP can provider tunneling 369 between NSP(s) and CP(s). 371 +-----------------+ 372 | user | 373 | | 374 +-----------------+ 375 ^ Access & Resource 376 | Request 377 v 378 +------------------+ 379 | NSP | 380 | | 381 +------------------+ 382 |^| 383 |:| 384 |:| 385 +-|:|--------------+ 386 | |:| TP | 387 | |:| | 388 +-|:|--------------+ 389 |:| 390 |:| Tunnel 391 |:| 392 |V| 393 +------------------+ 394 | CP | 395 | | 396 +------------------+ 398 In this model too, the relationship between NSP and TP and between 399 transit provider and CP can be 1:1, 1:N or M:N. 401 4.4 Constituent Logical Functional Components of the fully enabled AAA 402 Framework 404 Section 3.1 introduces the high-level AAA framework for multicasting. 405 Below is a diagram of a fully enabled multicasting network with AAA, 406 including the logical components within the various entities. 408 +-------------------------------+ 409 | user | 410 | | 411 +-------------------------------+ 412 ^ 413 | Access & resource request 414 v 415 +-------------------------------+ 416 | NSP | 417 | | 418 |+--------------+ +---------+| 419 ||NR Management |<-->|AAA Proxy|| (NR= network resource) 420 |+--------------+ RR +---------+| (RR= resource request) 421 +-------------------------------+ 422 ^ 423 | Access request 424 v 425 +------------------------------+ 426 | CP | 427 | | 428 | +---------+ | 429 | | AAA | | 430 | +---------+ | 431 +------------------------------+ 433 In the fully enabled model the NSP provides proxying of 434 authentication and authorization between the NSP and CP, as well as 435 user-based accounting. The AAA proxy server of the NSP communicates 436 with the CP's AAA server. Although not show in the above diagram 437 for the sake of simplicity, in addition to direct proxying between a 438 NSP and CP, this proxying may be done through a TP. This means that 439 the transit provider too is able to support AAA proxying. 441 In the fully enabled model the NSP also includes a component that 442 provides network resource management (e.g. QoS management), as 443 described in section 3.4, "Network Resource Management by NSP". 444 When a transit provider is used it may also provide Network Resource 445 management of its own resources. 447 4.5 Modularity of the framework 448 In the interest of flexibility, this framework is modular so that it 449 is possible that partially enabled versions of the models are 450 supported. A AAA-enabled version provides AAA functionality without 451 Network Resource management. A Network-Resource-Management-enabled 452 (QoS-enabled) version provides Network Resource management without 453 AAA functionality. Similarly, the possibility of one or more layers 454 of transit provision between an NSP and CP is in the interest of 455 modularity and extendibility. 457 5. IANA considerations 459 This memo does not raise any IANA consideration issues. 461 6. Security considerations 463 Refer to section 3.3. Also the user information related to 464 authentication with the CP should be protected in some way. 465 Otherwise, this memo does not raise any new security issues which 466 are not already existing in the original protocols. Enhancement of 467 multicast access control capabilities may enhance security 468 performance. 470 7. Conclusion 472 This memo provides a generalized framework for solution standards to 473 meet the requirements presented in MACCNT-REQ-draft. Further work 474 should be done to break down the content provider and network 475 service provider entities into their functional objects such as edge 476 devices, AAA servers, etc. 478 Normative References 480 [1] Hayashi, et. al., "Accounting, Authentication and Authorization 481 Issues in Well Managed IP Multicasting Services", draft-ietf- 482 mboned-maccnt-req-04.txt, February 2006, Work in Progress. 483 [2] Hayashi, et. al., "Issues Related to Receiver Access Control in 484 the Current Multicast Protocols", draft-ietf-mboned-rac-issues- 485 02.txt, March 2006, Work in Progress. 487 Authors' Addresses 489 Hiroaki Satou 490 NTT Network Service Systems Laboratories 491 3-9-11 Midoricho, Musashino-shi, Tokyo, 180-8585 Japan 492 Phone : +81 422 59 4683 493 Email : satou.hiroaki@lab.ntt.co.jp 495 Hiroshi Ohta 496 NTT Network Service Systems Laboratories 497 3-9-11 Midoricho, Musashino-shi, Tokyo, 180-8585 Japan 498 Phone : +81 422 59 3617 499 Email: ohta.hiroshi@lab.ntt.co.jp 501 Tsunemasa Hayashi 502 NTT Network Innovation Laboratories 503 1-1 Hikari-no-oka, Yokosuka-shi, Kanagawa, 239-0847 Japan 504 Phone: +81 46 859 8790 505 Email: hayashi.tsunemasa@lab.ntt.co.jp 507 Haixiang He 508 Nortel 509 600 Technology Park Drive 510 Billerica, MA 01801, USA 511 Phone: +1 978 288 7482 512 Email: haixiang@nortel.com 514 Comments 516 Comments are solicited and should be addressed to the mboned working 517 group's mailing list at mboned@lists.uoregon.edu_and/or the authors. 519 Full Copyright Statement 521 Copyright (C) The Internet Society (2006). 523 This document is subject to the rights, licenses and restrictions 524 contained in BCP 78, and except as set forth therein, the authors 525 retain all their rights. 527 This document and the information contained herein are provided on 528 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 529 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 530 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 531 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 532 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 533 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 535 Intellectual Property 537 The IETF takes no position regarding the validity or scope of any 538 Intellectual Property Rights or other rights that might be claimed 539 to pertain to the implementation or use of the technology described 540 in this document or the extent to which any license under such 541 rights might or might not be available; nor does it represent that 542 it has made any independent effort to identify any such rights. 543 Information on the procedures with respect to rights in RFC 544 documents can be found in BCP 78 and BCP 79. 546 Copies of IPR disclosures made to the IETF Secretariat and any 547 assurances of licenses to be made available, or the result of an 548 attempt made to obtain a general license or permission for the use 549 of such proprietary rights by implementers or users of this 550 specification can be obtained from the IETF on-line IPR repository 551 at http://www.ietf.org/ipr. 553 The IETF invites any interested party to bring to its attention any 554 copyrights, patents or patent applications, or other proprietary 555 rights that may cover technology that may be required to implement 556 this standard. Please address the information to the IETF at ietf- 557 ipr@ietf.org. 559 Expiration 561 This Internet-Draft will expire on October 6, 2006. 563 Acknowledgement 565 Funding for the RFC Editor function is currently provided by the 566 Internet Society.