idnits 2.17.1 draft-ietf-mboned-maccnt-req-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.a on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 734. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 752. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. 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. 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 are 8 instances of too long lines in the document, the longest one being 1 character in excess of 72. == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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 15, 2005) is 6951 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) No issues found here. Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Tsunemasa Hayashi, NTT 3 Internet Draft Haixiang He, Nortel 4 Document:draft-ietf-mboned-maccnt-req-00.txt Hiroaki Satou, NTT 5 Expires: October 15, 2005 Hiroshi Ohta, NTT 6 Susheela Vaidya, Cisco Systems 8 April 15, 2005 10 Accounting, Authentication and Authorization Issues in Well Managed 11 IP Multicasting Services 12 14 Status of this Memo 16 This document is an Internet-Draft and is subject to all provisions 17 of section 3 of RFC 3667. By submitting this Internet-Draft, each 18 author represents that any applicable patent or other IPR claims of 19 which he or she is aware have been or will be disclosed, and any of 20 which he or she become aware will be disclosed, in accordance with 21 RFC 3668. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six 29 months and may be updated, replaced, or obsoleted by other 30 documents at any time. It is inappropriate to use Internet-Drafts 31 as reference material or to cite them other than as "work in 32 progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on October 15, 2005 42 Copyright Notice 44 Copyright (C) The Internet Society (2005) 46 Abstract 48 This Internet Draft (I-D) describes problems in the area of 49 accounting and access control for multicasting. General 50 requirements for accounting capabilities including quality-of- 51 service (QoS) related issues are listed. This I-D assumes that 52 these capabilities can be realized by functions implemented at 53 edges of a network based on IGMP or MLD. By such functions, 54 information obtained from edge routers would be logged in a 55 dedicated database. Finally, cases for Content Delivery Services 56 (CDS) are described as application examples which could benefit 57 from multicasting accounting and access control capabilities as 58 described in the I-D. It is proposed that this I-D be used as a 59 starting point for further discussion on these issues. 61 Table of contents 63 Copyright Notice.................................................1 64 1. Introduction..................................................3 65 2. Definitions and Abbreviations.................................4 66 2.1 Definitions..................................................4 67 2.2 Abbreviations................................................4 68 3. Problem statement.............................................5 69 3.1 Accounting issues...........................................5 70 3.2 Relationship with secure multicasting (MSEC)................6 71 4. Functional general requirements for well managed IP 72 multicasting..................................................6 73 5. Application example and its specific requirements............10 74 5.1 IP Multicast-based Content Delivery Service (CDS): CP and 75 NSP are different entities (companies)......................10 76 5.1.1 Network model for Multicast Content Delivery Service......10 77 5.1.2 Content Delivery Service Requirements.....................12 78 5.1.2.1 Accounting Requirements.................................12 79 5.1.2.2 Authorization Requirements..............................13 80 5.1.2.3 Authentication Requirements.............................13 81 5.2 IP Multicast-based Content Delivery Service (CDS): CP and 82 NSP are the same entities (companies).......................14 83 6. IANA considerations..........................................15 84 7. Security considerations......................................15 85 8. Conclusion...................................................15 86 Normative References............................................16 87 Full Copyright Statement........................................17 88 Intellectual Property...........................................17 89 Acknowledgement.................................................17 91 1. Introduction 93 The intention of this Internet Draft (I-D) is to initiate a 94 discussion focused on accounting, authentication and authorization 95 issues for "well-managed IP multicasting" services ("well-managed" 96 defined at the end of this introduction). This I-D intends to 97 develop an informational RFC on requirements for "well-managed IP 98 multicasting". 100 IP multicasting is becoming widely used as a method to save network 101 resources such as bandwidth or CPU processing power of the sender's 102 server for cases where a large volume of information needs to be 103 distributed to a large number of receivers. This trend can be 104 observed both in enterprise use and in broadband services provided 105 by network operator/service providers. 107 Distance learning within a university and in-house (in-company) 108 sharing of multimedia information are examples of enterprise use. 109 In these examples, sources generate high-bit rate (e.g., 6Mbit/s) 110 streaming information. When the number of receivers becomes large, 111 such systems do not scale well without multicasting. 113 On the other hand, a Content Delivery Service (CDS) is an example 114 of a broadband service provided by network operators/service 115 providers. Distribution of movies and other video programs to each 116 user are typical services. Each channel requires large bandwidth 117 (e.g., 6Mbit/s) and operator/service providers need to provide many 118 channels to make their service attractive. In addition, the number 119 of receivers is large (e.g., more than a few thousands). The 120 system to provide this service does not scale well without 121 multicasting. 123 As such, multicasting can be useful to make the network more 124 scalable when a large volume of information needs to be distributed 125 to a large number of receivers. However, multicasting according to 126 current standards (e.g., IGMPv3[1] and MLDv2[2]) has drawbacks 127 compared to unicasting when one applies it to commercial services. 128 Accounting of each user's actions is not possible with multicasting 129 as it is with unicasting. Accounting consists of grasping each 130 user's behavior, when she/he starts/stops to receive a channel, 131 which channel she/he receives, etc. 133 IP multicasting can be used to distribute free material efficiently, 134 but there are limitations to multicasting in usage models where 135 usage accounting is necessary, such as many commercial applications. 136 Although multicasting has already been used in several applications, 137 in many cases it is used in such a way that accounting is not 138 necessary. Alternatively, one could develop and use a proprietary 139 solution to address this issue. However, non-standard solutions 140 have drawbacks in terms of interoperability or cost of development 141 and maintenance. 143 Without accounting capability in multicasting, information 144 providers desiring accounting capability are forced to use 145 unicasting even when multicasting would otherwise be desirable from 146 a bandwidth/server resource perspective. If multicasting could be 147 used with user-based accounting capabilities, its applicability 148 would be greatly widened. 150 This I-D first describes problems on accounting issues in 151 multicasting. Then the general requirements for this capability 152 including QoS related issues are listed. This I-D assumes that 153 these capabilities can be realized by functions implemented at 154 edges of a network based on IGMP or MLD. Such functions would 155 record into dedicated database information obtained from edge 156 routers. Finally, application examples which could benefit from 157 multicasting with accounting capabilities are shown. It is 158 proposed that this I-D be used as a starting point for a discussion 159 on these issues. 161 This I-D will present general functional requirements related to 162 accounting, authentication and authorization issues in IP 163 multicasting networks, and a multicast network which fulfills these 164 requirements will be called a "well managed" IP multicasting 165 network. 167 2. Definitions and Abbreviations 169 2.1 Definitions 171 Authentication: action for identifying a user as a genuine one. 173 Authorization: action for giving permission for a user to access 174 content or the network. 176 User-based accounting: actions for grasping each user's behavior, 177 when she/he starts/stops to receive a channel, which channel she/he 178 receives, etc. 180 2.2 Abbreviations 182 ASM: Any-Source Multicast 184 CDS: Content Delivery Service 186 CP: Content Provider 187 IGMP: Internet Group Management Protocol 189 MLD: Multicast Listener Discovery 191 NSP: Network Service Provider 193 SSM: Single-Source Multicast 195 QoS: Quality of Service 197 3. Problem statement 199 3.1 Accounting issues 200 In unicast communications, the server (information source) can 201 identify the client (information receiver) and only permits 202 connection by an eligible client when this type of access control 203 is necessary. In addition, when necessary, the server can grasp 204 what the client is doing (e.g., connecting to the server, starting 205 reception, what information the client is receiving, terminating 206 reception, disconnecting from the server). 208 On the other hand, in multicast communication as in Fig.1, the 209 server just feeds its information to the multicast router. Then, 210 the multicast router replicates the information to distribute to 211 the clients. According to current standards (e.g., IGMPv3[1] or 212 MLDv2[2]), the multicast router feeds the replicated information to 213 any link which has at least one client requesting the information. 214 In this process, no eligibility check is conducted. Any client can 215 receive information just by requesting it. In other words, the 216 current standards do not provide multicasting with authorization or 217 access control capabilities sufficient to meet the requirements of 218 accounting. 220 +--------+ 221 | user |\ 222 +--------+ \ 223 \+------+ +------+ +------+ +------+ 224 +--------+ |Multi-| |Multi-| |Multi-| | | 225 | user |---|cast |----|cast |----|cast |----|Server| 226 +--------+ |router| |router| |router| | | 227 /+------+ +------+ +------+ +------+ 228 +--------+ / 229 | user |/ 230 +--------+ 232 Fig.1 Example network for multicast communication 234 This is the major reason why multicasting is only used for cases 235 where no user-based accounting capabilities are necessary. However, 236 since more and more information is transferred over IP-based 237 networks and some of these applications may require accounting 238 capabilities, it is easy to envision the requirement of supporting 239 such cases. For example, accounting is needed if one wants to 240 charge for distributed information on a non-flat-fee basis. If the 241 volume of information and number of clients are large, it is 242 beneficial to use multicasting for purposes of network resource 243 efficiency. 245 As such, the same level of user-based accounting capabilities as 246 provided in unicast networks should be provided in multicast 247 networks. 249 3.2 Relationship with secure multicasting (MSEC) 251 In many cases, content encryption (e.g. MSEC) is an effective 252 method for preventing unauthorized access to original content (in 253 other words, the ability to decode data to return it to its 254 generally useable form.) This I-D presents requirements for 255 multicasting networks in the areas of 1) access control to prevent 256 unauthorized access to the network, and 2) accounting to grasp user 257 activity. It is not the intention of this I-D to propose 258 alternatives to encryption. Access control, accounting and 259 encryption are separate technologies. The implementation of any of 260 these technologies does not preclude the use of the others. 262 4. Functional general requirements for well managed IP multicasting 264 It seems beneficial to use IGMP or MLD for access controlling in 265 multicast networks. However, from the considerations presented in 266 section 3, there are issues in the following areas: 268 (1) User identification 270 The network should be able to identify each user when they attempt 271 to access the service so that necessary access controlling actions 272 can be applied. Also, it is necessary to identify the source 273 (user) of each request (e.g., join/leave) for user accounting 274 purposes. 276 With current protocols, the sender cannot distinguish which 277 receivers (end hosts) are actually receiving its information with 278 current protocols (IGMP/MLD.) The sender must rely on the 279 information from the multicasting routers. This can be complicated 280 if the sender and routers are maintained by different entities. 282 (2) Issue of network resource protection 284 In order to guarantee certain QoS it is important for network 285 providers to be able to protect their network resources from being 286 wasted, (either maliciously or accidentally). 288 (2.1) Access control 290 The network should be able to apply necessary access controlling 291 actions when an eligible user requests. The network should be able 292 to reject any action requested from an ineligible user. 294 (2.2) Control mechanism to support bandwidth of multicast stream 295 from a physical port of edge router or switch 297 The network should be able to control the combined bandwidth for 298 all groups both at the physical port of the edge router or switch 299 so that these given physical entities are not overflowed with 300 traffic. 302 (2.3) Control mechanism of number of groups delivered from a 303 physical port of edge router and switch 305 In order to enable an NSP to guarantee a certain level of QoS to 306 the CP and the receivers, it is important that the NSP can control 307 the number of groups delivered from a physical port of an edge 308 router and a switch so that the combined bandwidth between content 309 servers and multicast routers can be within the limit. 311 (3) User authentication 313 The network should be able to authenticate a user. 315 (4) User authorization 317 The network should be able to authorize a user's access to content 318 or a multicast group, so as to meet any demands by a CP to prevent 319 content access by ineligible users. Also, the NSP does not want to 320 waste their network resources on ineligible users. Eligibility can 321 be defined in several ways. The definition of an "eligible user" 322 should be discussed further. 324 (5) Accounting and billing 326 In many commercial multicast situations, NSP would like to be able 327 to precisely grasp network resource consumption and CP would like 328 to be able to precisely grasp the content consumption by end-users. 329 Such information might be used for "identifying highly viewed 330 content" for advertising revenue, ratings calculations, programming 331 decisions, etc., as well as billing and auditing purposes. Also 332 content and network providers may wish to provide users with access 333 to their usage history. 335 To assemble such an understanding of end-user behavior, it is 336 necessary to precisely log information such as who (host/user) is 337 accessing what content at what time (join action) until what time 338 (leave action). The result of the access-control decision (e.g. 339 results of authorization) would also be valuable information. The 340 desired degree of logging precisions would depend on the 341 application used. 343 Networks need database functions to realize user-based accounting 344 through the accumulation of logs from edge routers. 346 (5.1) How to share user information 348 For commercial multicast applications it is important for NSP and 349 CP to be able to share information regarding user's behaviour (as 350 described in (5) in standardized ways. 352 (6) Notification to users of the result of the join request 354 It should be possible to provide information to the user about the 355 status of his/her join request(granted/denied/other). 357 (7) Service and terminal portability 359 Networks should allow for a user to receive a service from 360 different places and/or with a different terminal device. 362 (8) Support of ASM and SSM 364 Both ASM (G), and SSM (S,G) should be supported as multicast models. 366 (9) Admission control for join action 368 In order to maintain a predefined QoS level, an edge router should 369 not accept a consequent "join" after a "leave" until the 370 termination of the stream of the multicast group which was "left". 371 This is essential to protect against e.g., multicast denial of 372 service (DoS) attacks. 374 (10) Channel Leave Latency 376 Commercial implementations of IP multicasting are likely to have 377 strict requirements in terms of user experience. Leave latency is 378 the time between when a user sends a signal that he/she wishes to 379 "leave" a group and when the network recognizes the "leave." 381 Leave latency impacts : 383 i. Acceptable end-user experience for fast channel surfing. 385 In an IP-TV application, users are not going to be receptive to 386 slow response time when changing channels. 388 ii. Resource consumption 390 With a low "leave latency" network providers could minimize 391 streaming content when there are no audiences. 393 It is important that any overhead for authentication, authorization, 394 and access-control be minimized at the times of joining and leaving 395 multicast groups so as to achieve join and leave latencies 396 acceptable in terms of user experience. For example this is 397 important in an IP-TV application, because users are not going to 398 be receptive to a slow response time when changing channels. 400 (11) Scalability 402 Solutions that are used for well managed IP multicasting should 403 scale enough to support the needs of content providers and network 404 operators. 406 (12) Small impact on the existing products 408 Impact on the existing products (e.g., protocols, software, etc.) 409 should be as minimal as possible. 411 Ideally the NSP should be able to use the same infrastructure (such 412 as access control) to support commercial multicast services for the 413 so called "triple play" services: voice (VoIP), video, and 414 broadband Internet access services. 416 (13) Deployable as alternative to Unicast 418 IP Multicasting would ideally be available as an alternative to IP 419 unicasting when the "on-demand" nature of unicasting is not 420 required. Therefore interfaces to multicasting should allow for 421 easy integration into CDS systems that support unicasting. 422 Especially equivalent interfaces for authorization, access control 423 and accounting capabilities should be provided. 425 (14) Multicast replication 426 The above requirements should also apply if multicast replication 427 is 428 being done on an access-node (e.g. DSLAMs or OLTs). 430 Specific functional requirements for each application can be 431 derived from the above general requirements. An example is shown 432 in the section 5. 434 5. Application example and its specific requirements 436 This section shows an application example which could benefit from 437 multicasting. Then, specific functional requirements related to 438 user-based accounting capabilities are derived. 440 5.1 IP Multicast-based Content Delivery Service (CDS): CP and NSP are 441 different entities (companies) 443 Broadband access networks such as ADSL (Asymmetric Digital 444 Subscriber Line) or FTTH (Fiber to the Home) have been deployed 445 widely in recent years. Content Delivery Service (CDS) is expected 446 to be a major application provided through broadband access 447 networks. Because many services such as television broadcasting 448 require huge bandwidth (e.g., 6Mbit/s) and processing power at 449 content server, IP multicast is used as an efficient delivery 450 mechanism for CDS. 452 One way to provide high quality CDS is to use closed networks 453 ("walled-garden" model). 455 This subsection shows an example where CP and NSP are different 456 entities (companies). 458 5.1.1 Network model for Multicast Content Delivery Service 459 As shown in Fig.2, networks for CDS contain three different types 460 of entities: Content Provider (CP), Network Service Provider (NSP), 461 and end user clients. An NSP owns the network resources 462 (infrastructure). It accommodates content providers on one side and 463 accommodates end user clients on the other side. NSP provides the 464 network for CDS to two other entities (i.e., CPs and end user 465 clients). A CP provides content to each end-user client through the 466 network of NSPs. NSPs are responsible for delivering the content to 467 end user clients, and for controlling the network resources. 469 +-------------+ +-------------+ +-------------+ 470 | CP | | CP | | CP | 471 | #1 | | #2 | | #3 | 472 | +---------+ | | +---------+ | | +---------+ | 473 | | content | | | | content | | | | content | | 474 | | server | | | | server | | | | server | | 475 | +-------+-+ | | +----+----+ | | +-+-------+ | 476 +----------\--+ +------|------+ +--/----------+ 477 \ | / 478 \ | / <- network/network 479 \ | / interface 480 +------------- \ ------ | ------ / ----+ 481 | \ | / | 482 | NSP +-+-----+-----+-+ | 483 | | Provider Edge | | 484 | +-------+-------+ | +-----------------+ 485 | | |---| Information | 486 | \ | | | server | 487 | +--+------+---+ | +-----------------+ 488 | | User Edge | | 489 | +--+---+---+--+ | 490 | / | \ | 491 +------------- / --- | --- \ ----------+ 492 / | \ 493 / | \ <- user/network interface 494 / | \ 495 +---------++ +-----+----+ ++---------+ 496 |client #a | |client #b | |client #c | 497 +----------+ +----------+ +----------+ 498 End user A End user B End user C 500 Fig.2 Example of CDS network configuration 502 The NSP provides the information server for all multicast channels, 503 and a CP gives detailed channel information (e.g., Time table of 504 each channel) to the information server. An end-user client gets 505 the information from the information server. In this model, 506 multicast is used in the NSP's CDS network, and there are two 507 different contracts. One is the contract between the NSP and the 508 end user which permits the user to access the basic network 509 resources of the NSP. Another contract is between the CP and end 510 user to permit the user to subscribe multicast content. Because the 511 CP and NSP are different entities, and the NSP generally does not 512 allow a CP to control (operate) the network resources of the NSP, 513 user authorization needs to be done by the CP and NSP independently. 514 Since there is no direct connection to the user/network interface, 515 the CP cannot control the user/network interface. An end user may 516 want to move to another place, or may want to change her/his device 517 (client) anytime without interrupting her/his receiving services. 518 As such, IP Multicast network should support portability 519 capabilities. 521 5.1.2 Content Delivery Service Requirements 523 To have a successful business providing multicast, there are some 524 specific requirements for the IP Multicast-based Content Delivery 525 Service. 527 5.1.2.1 Accounting Requirements 529 Since the CP and NSP are different business entities, they need to 530 share the profit. Such a profit sharing business relationship 531 requires accurate and near real-time accounting information about 532 the end user clients' activity on accessing the content services. 533 The accounting information should be per content/usage-base to 534 enable varied billing and charging methods. 536 The user accessing particular content is represented by the user's 537 activities of joining or leaving the corresponding multicast 538 group/channel ( or ). In multicast networks, only NSPs can 539 collect group joining or leaving activities through their last-hop 540 multicast access edge devices in real-time. The NSPs can transfer 541 the accounting information to related CPs for them to generate end 542 user billing information. The normal AAA technology can be used to 543 transfer the accounting information. 545 To match the accounting information with a particular end-user 546 client, the end-user client has to be authenticated. Usually the 547 account information of an end-user client for content access is 548 maintained by the CP. An end user client may have different user 549 accounts for different CPs. The account is usually in the format of 550 (username, password) so an end user client can access the content 551 services from anywhere. For example, an end user client can access 552 the CP from different NSPs. It should be noted that the user 553 account used for content access can be different from the one used 554 for network access maintained by NSPs. 556 The NSP-CP model represents a multi-domain AAA environment. There 557 are plural cases of the model depending on the trust relationship 558 between the NSP and CP, and additional service requirements such as 559 a certain QoS level guarantee or service/terminal portability. 561 A mechanism is necessary to allow a CP and NSP to grasp each user's 562 behavior independently. 564 Another requirement related to accounting is the ability to notify 565 a user when accounting really starts. When a "free preview" 566 capability is supported, accounting may not start at the same time 567 as the user's joining of the stream. 569 5.1.2.2 Authorization Requirements 571 The NSPs are responsible for delivering content and are required to 572 meet certain QoS levels or SLA (service level agreements). For 573 example, video quality is very sensitive to packet loss. So if an 574 NSP cannot meet the quality requirements due to limited network 575 resources if it accepts an additional user request, the NSP should 576 reject that end user's access request to avoid charging the 577 existing (i.e., already joined) user for bad services. For example, 578 if an access line is shared by several users, an additional user's 579 join may cause performance degradation for other users. If the 580 incoming user is the first user on an edge node, this will initiate 581 the transmission of data between the multicast router and the edge 582 node and this extra network traffic may cause performance 583 degradation. There may also be policies that do not necessarily 584 give highest priority to the "first-come" users, and these should 585 also be considered. 586 In order to protect network resources against misuse/malicious 587 access and maintain a QoS level, appropriate admission control 588 function for traffic policing purposes is necessary so that the NSP 589 can accept or reject the request without degrading the QoS beyond 590 the specified level. 592 5.1.2.3 Authentication Requirements 594 There are two different aims of authentication. One is 595 authentication for network access, and another one is for content 596 access. For the first case of authentication, NSP has a AAA server, 597 and for the second case, each CP has a AAA server. In some cases, 598 CPs delegate (outsource) the operation of user authentication to 599 NSPs. 601 As such, in addition to network access, multicast group access by a 602 user also needs to be authenticated. Content authentication should 603 support the models where: 604 - authentication for multicast content is outsourced to the 605 NSP. 606 - authentication for multicast content access is operated by 607 the content provider 609 5.2 IP Multicast-based Content Delivery Service (CDS): CP and NSP are 610 the same entities (companies) 612 Another application example is the case where the content provider 613 (CP) and network service provider (NSP) are the same entity 614 (company) as shown in Fig. 3. In the case that the CP and NSP are 615 the same entity, some of the requirements indicated in 4.1 are not 616 required. 618 This model does not require the following items: 620 - Communication method between sender (server) and user (end 621 host). Since they belong to the same company, they can use 622 all the available information. 624 - Methods to share user-related information between network 625 providers and content providers. 627 +-----------------------------------------------------+ 628 | +---------+ | 629 | | content | | 630 | | server | | 631 | +----+----+ | 632 | | | 633 | CP+NSP +-------+-------+ | 634 | | Provider Edge | | 635 | +-------+-------+ +--------------------+ | 636 | | | Information server | | 637 | | +--------------------+ | 638 | +-------------+ | 639 | | User Edge | | 640 | +--+---+---+--+ | 641 | / | \ | 642 +----------- / --- | --- \ ---------------------------+ 643 / | \ 644 / | \ <- user/network interface 645 / | \ 646 +---------++ +-----+----+ ++---------+ 647 |user #a | |user #b | |user #c | 648 +----------+ +----------+ +----------+ 649 End user A End user B End user C 651 Fig.3 Example of CDS network configuration 653 6. IANA considerations 655 This I-D does not raise any IANA consideration issues. 657 7. Security considerations 659 Accounting capabilities can be used to enhance the security of 660 multicast networks by excluding ineligible clients from the 661 networks. 663 8. Conclusion 665 This I-D describes general requirements for providing "well 666 managed" 667 IP multicasting services. It lists issues related to accounting, 668 authentication, authorization and admission control for multicast 669 content delivery, with the goal of finding a solution implemented 670 at edges of the network based on IGMP or MLD. This solution likely 671 would assume the existence of a database in the network dedicated 672 to accumulating logs obtained from edge routers. Content Delivery 673 Services with different business models is cited as an application 674 which could benefit from the capabilities of "well managed" IP 675 multicasting described in this document. 676 It is proposed that this document be used as a starting point for 677 discussing requirements for "well managed" IP multicasting services. 679 Normative References 681 [1] B. Cain, et. al., "Internet Group Management Protocol, Version 682 3", RFC3376, October 2002. 684 [2] R. Vida, et. al., "Multicast Listener Discovery Version 2 685 (MLDv2) for IPv6", RFC3810, June 2004. 687 Authors' Addresses 689 Tsunemasa Hayashi 690 NTT Network Innovation Laboratories 691 1-1 Hikarino'oka, Yokosuka-shi, Kanagawa, 239-0847 Japan 692 Phone: +81 46 859 8790 693 Email: hayashi.tsunemasa@lab.ntt.co.jp 695 Haixiang He 696 Nortel 697 600 Technology Park Drive Billerica, MA 01801, USA 698 Phone: +1 978 288 7482 699 Email: haixiang@nortel.com 701 Hiroaki Satou 702 NTT Network Service Systems Laboratories 703 3-9-11 Midoricho, Musashino-shi, Tokyo, 180-8585 Japan 704 Phone: +81 422 59 4683 705 Email: satou.hiroaki@lab.ntt.co.jp 707 Hiroshi Ohta 708 NTT Network Service Systems Laboratories 709 3-9-11 Midoricho, Musashino-shi, Tokyo, 180-8585 Japan 710 Phone: +81 422 59 3617 711 Email: ohta.hiroshi@lab.ntt.co.jp 713 Susheela Vaidya 714 Cisco Systems, Inc. 715 170 W. Tasman Drive San Jose, CA 95134 716 Phone: +1 408 525 1952 717 Email: svaidya@cisco.com 719 Full Copyright Statement 721 Copyright (C) The Internet Society (2004). 723 This document is subject to the rights, licenses and restrictions 724 contained in BCP 78, and except as set forth therein, the authors 725 retain all their rights. 727 This document and the information contained herein are provided on 728 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 729 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 730 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 731 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 732 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 733 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 734 PARTICULAR PURPOSE. 736 Intellectual Property 738 The IETF takes no position regarding the validity or scope of any 739 Intellectual Property Rights or other rights that might be claimed 740 to pertain to the implementation or use of the technology 741 described in this document or the extent to which any license 742 under such rights might or might not be available; nor does it 743 represent that it has made any independent effort to identify any 744 such rights. Information on the IETF's procedures with respect to 745 rights in IETF Documents can be found in BCP 78 and BCP 79. 747 Copies of IPR disclosures made to the IETF Secretariat and any 748 assurances of licenses to be made available, or the result of an 749 attempt made to obtain a general license or permission for the use 750 of such proprietary rights by implementers or users of this 751 specification can be obtained from the IETF on-line IPR repository 752 at http://www.ietf.org/ipr. 754 The IETF invites any interested party to bring to its attention any 755 copyrights, patents or patent applications, or other proprietary 756 rights that may cover technology that may be required to implement 757 this standard. Please address the information to the IETF at ietf 758 ipr@ietf.org. 760 Acknowledgement 762 Funding for the RFC Editor function is currently provided by the 763 Internet Society.