idnits 2.17.1 draft-ietf-mboned-multiaaa-framework-01.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 560. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 571. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 578. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 584. ** 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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. 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 (June 23, 2006) is 6518 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') -- Possible downref: Normative reference to a draft: ref. '2' Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft AAA Framework for Multicasting June 2006 4 Hiroaki Satou, NTT 5 Internet Draft Hiroshi Ohta, NTT 6 Expires: December 25, 2006 Tsunemasa Hayashi, NTT 7 Haixiang He, Nortel Networks 9 June 23, 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-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on December 25, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006) 42 Abstract 43 This memo provides a generalized framework for solution standards to 44 meet the requirements presented in draft-ietf-mboned-maccnt-req- 45 04.txt, "Requirements for Accounting, Authentication and 46 Authorization in Well Managed IP Multicasting Services". In this 47 framework a user sends a request for multicast data to a network 48 service provider. The network service provider selects the 49 appropriate content provider to send the user's request. The request 50 is sent by the network service provider to the content provider 51 transparently in a way so that the network service provider and 52 content provider do not need to know the corresponding user id for 53 the same user in the other provider's domain. The content provider 54 then responds with an indication of "success" or "failure" to the 55 network provider and in the case of "success", the network provider 56 may delivery the requested data to the user. The network service may 57 base its decision to deliver such data to the user based on its 58 bandwidth management policy. The framework is designed to be 59 flexible and extendible, so it will be possible to implement 60 partially enabled versions as well as fully enabled versions of the 61 model. Also an additional entity may provide transit of requests 62 between network service providers and content providers, either 63 through relaying or tunneling. 65 1. Introduction 67 1.1 Purpose and Background 69 IP multicasting is designed to serve cases where a single source of 70 data content is to be concurrently streamed to multiple recipients. 71 In these types of cases, multicasting provides resource efficiencies 72 (both for the overall network and the content server) relative to 73 unicasting. These efficiencies are possible because of the avoidance 74 of unnecessary duplication of streams, video/audio processing, etc. 75 Multicasting also provides resource efficiencies relative to IP 76 broadcasting in that content data is only delivered to end hosts 77 which request it. 79 There are many real-life situations where IP multicasting is selected 80 as the technology used for concurrent content delivery of identical 81 content data to multiple end-hosts. "Requirements for Accounting, 82 Authentication and Authorization in Well Managed IP Multicasting 83 Services", (draft-ietf-mboned-maccnt-req-04.txt, hereafter MACCNT- 84 REQ-draft) describes the requirements in CDN services using IP 85 multicast[1]. "Issues Related to Receiver Access Control in the 86 Current Multicast Protocols" (draft-ietf-mboned-rac-issues-03.txt, 87 hereafter RAC-ISSUES-draft) discusses the requirements and existing 88 support for large-scale, multi-entity content delivery services[2]. 89 The requirements are derived from: 90 - need for user tracking and billing capabilities 91 - need for network access control and/or content access control 92 to satisfy the requirements of the CP 93 - methods for sharing information between the network service 94 provider and content provider to make it possible to fulfill the 95 above two requirements. 97 Detailed requirements are presented in MACCNT-REQ-draft. These 98 requirements include mechanisms for recording end-user requests and 99 provider responses for content-delivery, sharing user information 100 (possibly anonymously depending on the trust model) between content 101 provider and network service provider, and protecting resources 102 through the prevention of network and content access by unauthorized 103 users, as well as other AAA related requirements. 105 The purpose of this memo is to provide a generalized framework for 106 solution standards to meet these requirements. This framework is to 107 provide a basis for defining protocols, but definition of the actual 108 protocols is outside of the scope of this memo. 110 2. Definitions and Abbreviations 112 2.1 Definitions 114 For the purposes of this memo the following definitions apply: 116 Accounting: actions for grasping each user's behavior, when she/he 117 starts/stops to receive a channel, which channel she/he receives, 118 etc. 120 Authentication: action for identifying a user as a genuine one. 122 Authorization: action for giving permission to access the content or 123 network to a user. 125 Receiver: an end-host or end-client which receives content. A 126 receiver may be distinguishable by a network ID such as MAC address 127 or IP address. 129 User: a human with a user account. A user may possibly use multiple 130 reception devices. Multiple users may use the same reception device. 132 Note: The definition of a receiver (device) and a user (human) should 133 not be confused. 135 2.2 Abbreviations 137 For the purposes of this draft the following abbreviations apply: 139 ACL: Access Control List 141 CDN: Content Delivery Network 143 CDS: Content Delivery Services 145 CP: Content Provider 147 NSP: Network Service Provider 149 TP: Transit Provider 151 3. Framework and Roles of Entities 153 3.1 Framework for multicast AAA allowing bandwidth Management 155 A general high-level framework can be represented as follows. 157 +------------------------------+ 158 | user | 159 | | 160 +------------------------------+ 161 | Access ^ Response 162 | Request | & Multicast Data 163 V | 164 +------------------------------+ 165 | NSP | 166 | | 167 +------------------------------+ 168 | Access ^ Response 169 | Request | (Success) 170 v | 171 +------------------------------+ 172 | CP | 173 | | 174 +------------------------------+ 176 For the sake of simplicity, the above diagram portrays a case where 177 there is a single NSP entity and a single CP entity. Under the 178 framework it is possible for there to be multiple CPs connected to 179 the same NSP. It is also possible for the same CP to be connected to 180 multiple NSP networks (e.g. network selection). In other words the 181 relationship of NSP:CP can be described as 1:1, 1:N or M:N. 182 Furthermore it is possible that the NSP and CP could be the same 183 entity. 185 Description of Roles: 187 The user selects a CP and a NSP when the user requests content. The 188 NSP may be automatically selected by a user terminal: e.g. a fixed 189 line NSP for STB or a mobile NSP for mobile phone. 191 The CP is responsible for Authentication and Authorization of users' 192 access to content that the CP manages. The CP hopes to collect 193 accounting information related to the access of their content. The CP 194 may choose to authenticate and authorize NSPs which are eligible to 195 provide users access to its contents. When the CP cannot or decides 196 not to provide content to be multicast to users, the CP is 197 responsible for notifying the NSP of the reason. 199 The NSP is responsible for managing its network resources. The NSP 200 may perform admission control to protect bandwidth resource and needs 201 authorized information regarding user access for bandwidth 202 management. 203 It is also responsible for confirming (authentication by proxy) with 204 the CP whether the user is eligible to receive content. When the NSP 205 cannot or decides not to multicast to users, the NSP is responsible 206 for notifying the users of the reason. 207 In addition to the three basic entities of user, NSP and CP, this AAA 208 framework for multicasting supports transit provision which transfers 209 multicast streams from the CP to the NSP. 211 3.2 Multiple User IDs 213 Users may be assigned separate user IDs for each subscription for 214 various NSPs and CPs. When the user wants to access content or 215 otherwise use the network, the user registers the corresponding user 216 ID with a request for content, etc: web authentication is one 217 possible method. 219 Terminal portability can be realized if the NSP authenticates a user 220 using a user ID. This allows the user to access the content from 221 various network access points. 223 Each CP may identify users by the user IDs it has issued to them. 225 The NSP and CP do not need to know the corresponding user id for the 226 same user in the other provider's domain, and it is not necessary 227 that there is a one to one relationship. It is quite possible for 228 one person to hold multiple user ids for the same provider. 230 3.3 Accounting 232 The NSP should not manage multicast states on a subnet basis, but on 233 a user basis because the NSP needs to notify start and stop times for 234 accounting purposes. This means that the NSP sends an indication for 235 Join and Leave on a user basis. 237 The NSP should log both user and host information for each join and 238 leave, indicating the corresponding multicast source for each action. 239 It is important that such log use a standard format so that it can be 240 shared with the CP. Intermittent logs between the join and leave 241 also could serve useful in billing discrepancies, and disconnects 242 without leaves. Ideally a solution would also provide standard ways 243 for the NSP to share logged information with the CP. When shared it 244 is important that the CP be able to match the user to the user within 245 its domain. 247 3.4 Access Control and CP selection by NSP 249 When a NSP receives an access request from a user, it is necessary 250 for the NSP to determine to which CP the request is directed. It is 251 necessary for the NSP to ensure that it is not spoofed by an 252 inappropriate CP. 254 3.5 Network Resource Management by NSP 256 After authorizing a user request, the NSP may conduct admission 257 control based on its bandwidth management policy. For example, if the 258 NSP manages the shared bandwidth of access lines, the NSP might 259 calculate available bandwidth and necessary bandwidth, and based on 260 these calculations determine to accept or reject a user request. 262 3.6 Access Control and Distinguishing of Users by CP 264 The user ID and authentication information are forwarded 265 transparently by the NSP so that the CP can distinguish the user, as 266 well as authenticate and authorize the request. 268 3.7 Caching of AAA results 270 An NSP should be able to cache AAA results based an understanding 271 between the NSP and a CP. The AAA cache would store information 272 about permissions of a specific user to receive multicast data from 273 specified channel(s) up to specified expiration date(s) and time(s). 274 If such caching is implemented, a method must exist for the CP to 275 communicate this permission information to the NSP. The NSP refers 276 to the AAA cache and if the cache indicates that the user has 277 permission to receive multicast data from a specific channel at that 278 time, the NSP may forward the data without querying the CP. 280 It should be possible for a CP to send a directive to the NSP to 281 refresh or change permissions for a user for specific channel(s). 283 It is necessary for the NSP to requery the CP for authorization 284 should a user be receiving content when the permission expires. 286 It would be desirable to have a mechanism by which CPs could 287 proactively push permission information to the cache even when not 288 specifically queried by the NSP. 290 4. Network Connection Model and Functional Components 292 Section 3.1 introduces the high-level AAA framework for multicasting. 293 This section provides more detail on the network connection model and 294 constituent functional components. 296 4.1 Basic Connection Model 297 +-------------+ 298 | user | 299 | | 300 +-------------+ 301 ^ Access & Resource 302 | Request 303 v 304 +-------------+ 305 | NSP | 306 | | 307 +-------------+ 308 ^ Access 309 | Request 310 v 311 +-------------+ 312 | CP | 313 | | 314 +-------------+ 316 First a user desiring authorization sends an Access request to an NSP 317 which then forwards it on to the appropriate CP for Authentication 318 and Authorization. The CP responds with either "success" or 319 "failure". If "success", the NSP may forward a success response 320 and stream multicast data to the user. 322 In this model the user selects the NSP to which to send its content 323 request. Based on this request the NSP selects an appropriate CP to 324 which it forwards the request. The CP responds to the NSP's request: 325 it may not respond to another NSP in regards to the request. 327 In this model, as described in section 3.1, the relationship between 328 NSP and CP can be 1:1, 1:N or M:N. Users may connect to multiple 329 networks, and networks have multiple users. 331 4.2 Transit Provision 333 The diagram below shows that a Transit Provider(hereafter, TP) may 334 relay requests between NSPs and CPs. 336 +-------------+ 337 | user | 338 | | 339 +-------------+ 340 ^ Access & Resource 341 | Request 342 v 343 +-------------+ 344 | NSP | 345 | | 346 +-------------+ 347 ^ Access & Resource 348 | Request 349 v 350 +-------------+ 351 | TP | 352 | | 353 +-------------+ 354 ^ Access 355 | Request 356 v 357 +-------------+ 358 | CP | 359 | | 360 +-------------+ 362 For the sake of simplification the above diagram shows a 1-1 363 relationship between an NSP and a TP. However it is also possible 364 for a single NSP to connect to multiple TPs, and a single TP to 365 multiple NSPs. 367 A single TP may connect to one or more CPs. Similarly just as a 368 single CP may connect to multiple NSPs (as described in the general 369 high-level framework, section 3.1), a single CP may connect to one or 370 more TPs. 372 A solution will include a mechanism through which the NSPs know which 373 TP(s) are to be used to communicate with which CP(s), and CPs know 374 which TP(s) to use for which NSP(s). When a TP receives an access or 375 resource request from an NSP or CP, it must relay the request to the 376 correct CP or NSP, respectively. Minimally, this means that it must 377 reconstruct the request with translated address information. In this 378 model therefore a TP must understand the format and meaning of the 379 requests. 381 There may be multiple TPs between a NSP and CP so that a TP is 382 actually receiving from and/or sending requests to another TP and not 383 directly from/to a NSP or CP. 385 4.3 Transit with Tunnels 387 In addition to the above model of request relaying, a TP may 388 communicate requests through tunneling based on the contract between 389 the TP and the NSP and/or between the TP and the CP. So in this case 390 the TP will not directly need to process the contents of the access 391 and resource request (such as, header information), but instead pass 392 the request directly to the correct NSP or CP, using a separate 393 protocol to wrap the original requests. 395 Below is a diagram, representing how a TP can provider tunneling 396 between NSP(s) and CP(s). 398 +-----------------+ 399 | user | 400 | | 401 +-----------------+ 402 ^ Access & Resource 403 | Request 404 v 405 +------------------+ 406 | NSP | 407 | | 408 +------------------+ 409 |^| 410 |:| 411 |:| 412 +-|:|--------------+ 413 | |:| TP | 414 | |:| | 415 +-|:|--------------+ 416 |:| 417 |:| Tunnel 418 |:| 419 |V| 420 +------------------+ 421 | CP | 422 | | 423 +------------------+ 425 In this model too, the relationship between NSP and TP and between 426 transit provider and CP can be 1:1, 1:N or M:N. 428 4.4 Constituent Logical Functional Components of the fully enabled AAA 429 Framework 431 Section 3.1 introduces the high-level AAA framework for multicasting. 432 Below is a diagram of a fully enabled multicasting network with AAA, 433 including the logical components within the various entities. 435 +-------------------------------+ 436 | user | 437 | | 438 +-------------------------------+ 439 ^ 440 | Access & resource request 441 v 442 +-------------------------------+ 443 | NSP | 444 | | 445 |+--------------+ +---------+| 446 ||NR Management |<-->|AAA Proxy|| (NR= network resource) 447 |+--------------+ RR +---------+| (RR= resource request) 448 +-------------------------------+ 449 ^ 450 | Access request 451 v 452 +------------------------------+ 453 | CP | 454 | | 455 | +---------+ | 456 | | AAA | | 457 | +---------+ | 458 +------------------------------+ 460 In the fully enabled model the NSP provides proxying of 461 authentication and authorization between the NSP and CP, as well as 462 user-based accounting. The AAA proxy server of the NSP communicates 463 with the CP's AAA server. Although not show in the above diagram for 464 the sake of simplicity, in addition to direct proxying between a NSP 465 and CP, this proxying may be done through a TP. This means that the 466 transit provider too is able to support AAA proxying. 468 In the fully enabled model the NSP also includes a component that 469 provides network resource management (e.g. QoS management), as 470 described in section 3.4, "Network Resource Management by NSP". When 471 a transit provider is used it may also provide Network Resource 472 management of its own resources. 474 4.5 Modularity of the framework 475 In the interest of flexibility, this framework is modular so that it 476 is possible that partially enabled versions of the models are 477 supported. A AAA-enabled version provides AAA functionality without 478 Network Resource management. A Network-Resource-Management-enabled 479 (QoS-enabled) version provides Network Resource management without 480 AAA functionality. Similarly, the possibility of one or more layers 481 of transit provision between an NSP and CP is in the interest of 482 modularity and extendibility. 484 5. IANA considerations 486 This memo does not raise any IANA consideration issues. 488 6. Security considerations 490 Refer to section 3.3. Also the user information related to 491 authentication with the CP should be protected in some way. 492 Otherwise, this memo does not raise any new security issues which are 493 not already existing in the original protocols. Enhancement of 494 multicast access control capabilities may enhance security 495 performance. 497 7. Conclusion 499 This memo provides a generalized framework for solution standards to 500 meet the requirements presented in MACCNT-REQ-draft. Further work 501 should be done to break down the content provider and network service 502 provider entities into their functional objects such as edge devices, 503 AAA servers, etc. 505 Normative References 507 [1] Hayashi, et. al., "Accounting, Authentication and Authorization 508 Issues in Well Managed IP Multicasting Services", draft-ietf- 509 mboned-maccnt-req-04.txt, February 2006, Work in Progress. 510 [2] Hayashi, et. al., "Issues Related to Receiver Access Control in 511 the Current Multicast Protocols", draft-ietf-mboned-rac-issues- 512 03.txt, April 2006, Work in Progress. 514 Authors' Addresses 516 Hiroaki Satou 517 NTT Network Service Systems Laboratories 518 3-9-11 Midoricho, Musashino-shi, Tokyo, 180-8585 Japan 519 Phone : +81 422 59 4683 520 Email : satou.hiroaki@lab.ntt.co.jp 522 Hiroshi Ohta 523 NTT Network Service Systems Laboratories 524 3-9-11 Midoricho, Musashino-shi, Tokyo, 180-8585 Japan 525 Phone : +81 422 59 3617 526 Email: ohta.hiroshi@lab.ntt.co.jp 528 Tsunemasa Hayashi 529 NTT Network Innovation Laboratories 530 1-1 Hikari-no-oka, Yokosuka-shi, Kanagawa, 239-0847 Japan 531 Phone: +81 46 859 8790 532 Email: tsunemasa@gmail.com 534 Haixiang He 535 Nortel 536 600 Technology Park Drive 537 Billerica, MA 01801, USA 538 Phone: +1 978 288 7482 539 Email: haixiang@nortel.com 541 Comments 543 Comments are solicited and should be addressed to the mboned working 544 group's mailing list at mboned@lists.uoregon.edu_and/or the authors. 546 Full Copyright Statement 548 Copyright (C) The Internet Society (2006). 550 This document is subject to the rights, licenses and restrictions 551 contained in BCP 78, and except as set forth therein, the authors 552 retain all their rights. 554 This document and the information contained herein are provided on an 555 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 556 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 557 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 558 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 559 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 560 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 562 Intellectual Property 564 The IETF takes no position regarding the validity or scope of any 565 Intellectual Property Rights or other rights that might be claimed to 566 pertain to the implementation or use of the technology described in 567 this document or the extent to which any license under such rights 568 might or might not be available; nor does it represent that it has 569 made any independent effort to identify any such rights. Information 570 on the procedures with respect to rights in RFC documents can be 571 found in BCP 78 and BCP 79. 573 Copies of IPR disclosures made to the IETF Secretariat and any 574 assurances of licenses to be made available, or the result of an 575 attempt made to obtain a general license or permission for the use of 576 such proprietary rights by implementers or users of this 577 specification can be obtained from the IETF on-line IPR repository at 578 http://www.ietf.org/ipr. 580 The IETF invites any interested party to bring to its attention any 581 copyrights, patents or patent applications, or other proprietary 582 rights that may cover technology that may be required to implement 583 this standard. Please address the information to the IETF at ietf- 584 ipr@ietf.org. 586 Expiration 588 This Internet-Draft will expire on December 25, 2006. 590 Acknowledgement 592 Funding for the RFC Editor function is currently provided by the 593 Internet Society.