idnits 2.17.1 draft-hayashi-rac-issues-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 837. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 855. ** 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 5 instances 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 (~~), 2 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 Networks 4 Expires: August 13, 2005 Hiroaki Satou, NTT 5 Hiroshi Ohta, NTT 6 Susheela Vaidya, Cisco Systems 8 February 13 2005 10 Issues Related to Receiver Access Control in the Current Multicast 11 Protocols 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-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on August 13, 2005 40 Copyright Notice 42 Copyright (C) The Internet Society (2005) 44 Abstract 46 This I-D lists and describes issues related to receiver access 47 control in current multicasting protocols which are especially 48 important to commercial, large-scale multicasting. A few common 49 business models for content and network provision are presented to 50 provide background and explain the motivation of this work. Four 51 existing possible multicasting architectures (with or without some 52 form of access or content control) are presented. Then each 53 architecture is analyzed with respect to how it can or cannot 54 satisfactorily address each issue. This I-D concludes that for many 55 of these issues the possible architectures based on present standards 56 as they now exist require non-standardized solutions to meet common 57 use requirements. This I-D recommends for requirements to be defined 58 that would set the groundwork for creating standardized ways to 59 overcome these limitations. 61 Copyright Notice...................................................1 62 1. Introduction....................................................3 63 2. Definitions and Abbreviations...................................4 64 2.1 Definitions....................................................4 65 2.2 Abbreviations..................................................5 66 3. Common use models and network architecture implications.........5 67 4. Issues in multicasting related to commercial and large-scale 68 implementations....................................................6 69 4.1 Access limits and resource issues..............................6 70 4.1.1 Access limit for multicast groups............................6 71 4.1.2 Maintain guaranteed quality-level of data delivery (Voice, 72 Video).............................................................7 73 4.1.3 Issue of network resource protection.........................7 74 4.1.3.1 Control mechanism to support bandwidth of multicast stream 75 from a physical port of edge router or switch......................7 76 4.2 Capability to distinguish between receivers (end hosts)........7 77 4.3 Capability to distinguish between users (as opposed to merely 78 hosts).............................................................8 79 4.4 Channel "leave latency"........................................8 80 4.5 Surveillance of receiver by sender.............................9 81 4.5.1 Precise access log...........................................9 82 4.5.2 How to share user information................................9 83 4.5.3 Trustworthy logs to monitor user activity....................9 84 4.6 Notification to users of the result of the join request.......10 85 4.7 Triple Play...................................................10 86 4.8 DRM Protection................................................10 87 5. Description of existing architectures..........................10 88 5.1 IGMP/MLD......................................................10 89 5.2 IGMP/MLD with L2 Authentication with ACL......................11 90 5.3 Unicast Control with IGMP/MLD.................................12 91 5.4 IGMP/MLD with Multicast Encryption............................12 92 6. Evaluation of architectures by issue...........................13 93 6.1 Access limit capabilities, compared by architecture...........13 94 6.2 Capability to distinguish between receivers, compared by 95 architecture......................................................14 96 6.3 Capability to distinguish between users, compared by architecture 97 ..................................................................14 98 6.4 Maintain guaranteed quality-level of data delivery (Voice, Video), 99 compared by architecture..........................................15 100 6.5 Fast leave for fast surfing capability, compared by architecture 101 ..................................................................15 102 6.6 Surveillance of receiver by sender, compared by architecture..16 103 6.7.Notification to users of the result of the join request compared 104 by architecture...................................................16 105 6.8 Triple Play capability, compared by architecture..............17 106 7. IANA considerations............................................17 107 8. Security considerations........................................17 108 9. Conclusion.....................................................17 109 Normative References..............................................18 110 Full Copyright Statement..........................................19 111 Intellectual Property.............................................19 112 Acknowledgement...................................................19 114 1. Introduction 116 The intention of this I-D is to initiate a discussion on issues 117 related to receiver access control in the current multicast protocols 118 especially when deployed for commercial, large-scale multicasting. 119 It is hoped that further drafts will define requirements to address 120 the issues raised in this draft. 122 Existing IP multicasting protocols (as presented in Section 5) were 123 designed to meet certain sets of requirements that do not necessarily 124 include architectural considerations intended to support commercial 125 services. This I-D presents a number of issues network providers may 126 face when they attempt to apply current multicasting standards to 127 commercial services. The extent to which existing multicast 128 protocols can or cannot satisfactorily deal with issue is explored. 129 A few network models based on a range of different business models 130 are presented as a basis for defining requirements in a future 131 document. 133 IP multicasting is becoming widely used as a method to save network 134 resources such as bandwidth or CPU processing power of the sender's 135 server for cases where a large volume of information needs to be 136 distributed to a large number of receivers. This trend can be 137 observed both in enterprise use and in broadband services provided by 138 network operator/service providers. 140 Distance learning within a university and in-house (in-company) 141 sharing of multimedia information are examples of enterprise use. In 142 these examples, sources generate high-bit rate (e.g., 6Mbit/s) 143 streaming information. When the number of receivers becomes large, 144 such systems do not scale well without multicasting. 146 On the other hand, content delivery service (CDS) is an example of a 147 broadband service provided by network operators/service providers. 148 Distribution of movies and other video programs to each user are 149 typical services. Each channel requires large bandwidth (e.g., 150 6Mbit/s) and operator/service providers need to provide many channels 151 to make their service attractive. In addition, the number of 152 receivers is large (e.g., more than a few thousands). The system to 153 provide this service does not scale well without multicasting. 155 As such, multicasting can be useful to make the network more scalable 156 when a large volume of information needs to be distributed to a large 157 number of receivers. However, multicasting according to current 158 standards (e.g., IGMPv3[1] and MLDv2[2]) has drawbacks compared to 159 unicasting. This I-D first presents a few common business models for 160 content and network provision in order to provide background and 161 explain the motivation of this work. Then, issues which are important 162 for commercial, large-scale implementations of multicasting are 163 listed. Next, a few possible existing architectures used for 164 multicasting with access control based on current standards are 165 presented. Specifically 1) IGMP/ MLD, 2) IGMP/MLD with L2 166 Authentication with ACL 3) Unicast Control with IGMP/MLD and 4) 167 IGMP/MLD with Multicast Encryption will each be presented and 168 described. Each architecture is discussed with respect to the 169 presented list of issues. 171 2. Definitions and Abbreviations 173 2.1 Definitions 175 For the purposes of this I-D the following definitions apply: 177 Accounting: actions for grasping each user's behavior, when she/he 178 starts/stops to receive a channel, which channel she/he receives, etc. 180 Authentication: action for identifying a user as a genuine one. 182 Authorization: action for giving permission to access the content or 183 network to a user. 185 Receiver: an end-host or end-client which receives content. A 186 receiver may be distinguishable by a network ID such as MAC address 187 or IP address. The receiver should be distinguished from the user 188 (see below.) 190 User: a human with a user account. A user may possibly use multiple 191 reception devices. Multiple users may use the same reception device. 193 2.2 Abbreviations 195 For the purposes of this draft the following abbreviations apply: 197 ACL: Access Control List 199 CDS: Content Delivery Services 201 CSP: Content Service Provider 203 DRM: Data Rights Management 205 KEI: Key Exchange Identifier 207 NSP: Network Service Provider 209 QoS: Quality of Service 211 3. Common use models and network architecture implications 213 Issues such as user identification, access-control, tracking and 214 billing are common requirements for commercial content delivery 215 services (CDS) systems (and are important in many non-commercial CDS 216 systems as well.) These same requirements should be met for CDS 217 systems that employ multicasting. 219 In some cases a single entity may design and be responsible for a 220 system that covers the various common high-level requirements of a 221 commercial multicasting system such as 1) content serving, 2) the 222 infrastructure to multicast it, 3) network and content access control 223 mechanisms. 225 However it should not be assumed that the entity responsible for the 226 multicasting structure and the entity responsible for content serving 227 are the same. Indeed because the infrastructure for multicasting is 228 expensive and many content holders are not likely to be competent at 229 building and maintaining complicated infrastructures necessary for 230 multicasting, many content holders would prefer to purchase the 231 services from a network service provider and thus share the 232 infrastructure costs with other content holders. 234 Similarly commercial network service providers do not generally 235 specialize in providing content and are unlikely to build and 236 maintain such a resource-intensive system without a certain level of 237 demand from content holders. 239 The business model of a single NSP providing multicasting services to 240 multiple CSP has certain implications: 242 -Need for user tracking and billing capabilities 243 -Need for network access control and/or content access control 244 satisfactory to the requirements of the CSP 245 -Methods for sharing information between the NSP and CSP to make 246 the above two possible 248 When the NSP and CSP are the same single entity the general 249 requirements are as follows. 251 -Need for user tracking and user-billing capabilities 252 -Need for access control and/or content protection at level the 253 entity deems appropriate 255 In the next section issues in multicasting related to commercial and 256 large-scale implementations are presented. Some presented issues are 257 not pertinent to cases where the NSP and CSP are the same entity. 259 4. Issues in multicasting related to commercial and large-scale 260 implementations 262 This section lists issues related to receiver access control in 263 current multicasting protocols which are especially important to 264 commercial, large-scale multicasting. 266 4.1 Access limits and resource issues 268 4.1.1 Access limit for multicast groups 270 For commercial applications of multicasting network and content 271 providers generally wish to be able to control the number of groups a 272 host can access at the same time. If any user can access any group 273 without limitation network providers may waste network resources, and 274 this may have implications on the Quality of Service (QoS) they can 275 provide to other users. Access control is also important to prevent 276 against unauthorized access of data as it is a priority of many 277 content providers to control access to their content from reasons 278 ranging to IPR issues to privacy issues. 280 4.1.2 Maintain guaranteed quality-level of data delivery (Voice, Video) 282 For NSP to guarantee and charge for a certain quality of data 283 delivery it is important that they can limit the number of receivers 284 to a level that their bandwidth and servers can handle. 286 With best-effort services (e.g. mail transfer, web surfing) strict 287 network resource allocation is not necessary, but for services with a 288 guaranteed QoS level (e.g. IP television, teleconferencing, VoIP) it 289 is necessary to allocate sufficient bandwidth and server resources to 290 each service. 292 4.1.3 Issue of network resource protection 294 In order to guarantee certain QoS levels as described in the above 295 section (4.1.2), it is important for network providers to be able to 296 protect their network resources from being wasted, (either 297 maliciously or accidentally). 299 4.1.3.1 Control mechanism to support bandwidth of multicast stream from 300 a physical port of edge router or switch 302 The network should be able to control the combined bandwidth for all 303 groups both at the physical port of the edge router or switch and on 304 each link between routers and/or NW switches so that these given 305 physical entities are not overflown by the traffic. 307 4.1.3.2. Number of groups delivered from a physical port of edge router 308 and switch 310 So that the NSP can guarantee a certain level of QoS to the CSP and 311 the receivers it is important that it be able to control the number 312 of groups that are served from any certain edge router or switch at 313 any certain time. 315 When the NSP and the CSP are the same entity the QoS obligations are 316 simplified since guarantees would be made only to the users. 318 4.2 Capability to distinguish between receivers (end hosts) 320 Currently the sender cannot distinguish which receivers (end hosts) 321 are actually receiving its information with current protocols 322 (IGMP/MLD.) The sender must rely on the information from the 323 multicasting routers. This can be complicated if the sender and 324 routers are maintained by different entities. There is currently no 325 standard way to share such information. 327 4.3 Capability to distinguish between users (as opposed to merely 328 hosts) 330 Many content providers would like to have detailed information on 331 what users are consuming their content and information on their usage 332 behavior. This information might be used for ratings information, 333 billing, auditing, and programming decisions. Also content and 334 network providers may wish to provide users with access to their 335 usage history. If a network provider and content provider are 336 separate entities there are no protocols for sharing such information 337 on a user basis. 339 For example, if NSPs are going to provide access control and/or usage 340 information to a CSP on a user level it is important that the two 341 entities be able to distinguish users and communicate appropriate 342 information. For example, it is quite conceivable that a CSP might 343 want to bill or track separate users who may use the same device 344 (such as at Internet cafes, at hotels, with families, etc.) In such a 345 case it is important that the NSP record information on who is 346 actually downloading data on the user-level since the CSP would 347 otherwise not be able to receive this information. Also for example, 348 in many usage models it is important to provide portability, in other 349 words to allow users to access the network from different devices 350 and/or different access points. If NSPs are going to provide access 351 control and/or billing capability to a separate-entity CSP, this 352 capability of distinguishing users is important. 354 If the same entity is providing both content and network services, 355 the entity has access to sufficient data to distinguish users. 356 Nevertheless a standard way of relaying this information between 357 servers on the network would be attractive from the standpoint of 358 potential decreased development and operational costs. 360 4.4 Channel "leave latency" 362 Commercial implementations of IP multicasting are likely to have 363 strict requirements in terms of user experience. Leave latency is 364 the time between when a user sends a signal that he/she wishes to 365 "leave" a group and when the network recognizes the "leave." 367 Leave latency impacts : 368 i. Acceptable end-user experience for fast channel surfing. 370 In an IP-TV application, users are not going to be 371 receptive to slow response time when changing channels. 373 ii. Resource consumption 374 With a low "leave latency" network providers could 375 minimize streaming content when there are no audiences. 377 4.5 Surveillance of receiver by sender 379 4.5.1 Precise access log 381 In many commercial multicast situations, NSP and CSP would like to be 382 able to precisely grasp the content consumption of end-users. Such 383 information might be used for "identifying highly viewed content" for 384 advertising revenue, ratings calculations, programming decisions, etc. 386 To assemble such an understanding of end-user behavior, it is 387 necessary to precisely log information such as who (host/user) is 388 accessing what content at what time (join action) until what time 389 (leave action). The result of the access-control decision (e.g. 390 results of authorization) would also be valuable information. 392 4.5.2 How to share user information 394 For commercial multicast applications where NSP and CSP are different 395 entities, there are a number of issues regarding how to share user 396 information between the NSP and CSP. For example, which entities 397 should be able to access which information relating to user-based 398 tracking? What is the user identifier that can be used between the 399 entities to distinguish among users, and which entities should be 400 able to recognize this identifier? Another important issue is how 401 the edge router should be able to access and then maintain user 402 information. The current situation of present architectures is that 403 only the NSP can get information about user activity, because user 404 activities are only observable from join/leave information logged on 405 edge devices which are under control of the NSP. 407 4.5.3 Trustworthy logs to monitor user activity 409 An important issue for commercial multicasting applications is how 410 the NSP can get trustworthy data on user activity which may be needed 411 for billing and statistics purposes. A standard way of logging user 412 activity and protecting the integrity of the logs does not exist. 413 Often network providers do not want to keep logs on untrusted user 414 terminal which can be tampered with. 416 4.6 Notification to users of the result of the join request 418 It is necessary to provide information to the user about the status 419 of his/her join request(granted/denied/other). 421 4.7 Triple Play 423 Ideally the NSP should be able to use the same infrastructure (such 424 as access control) to support commercial multicast services for the 425 so called "triple play" services: voice (VoIP), video, and broadband 426 Internet access services. 428 4.8 DRM Protection 430 Digital Rights Management (DRM) is important but out of scope of this 431 I-D. 433 5. Description of existing architectures 435 In this section, existing architectures used for multicasting based 436 on current standards are defined. In section 6 these architectures 437 will be compared by the issues presented in section 4. 439 5.1 IGMP/MLD 441 Internet Group Management Protocol(IGMP) or Multicast Listener 442 Discovery (MLD) are protocols for layer 3 management of multicasting. 443 In IP multicast a receiver sends a request to a first-hop multicast 444 router to join a particular multicast group. The router is then 445 responsible for forwarding the appropriate data from the sender to 446 the receiver. 448 +----------+ +----------+ +----------+ +----------+ 449 | Sender | | Router | | L2SW | | Receiver | 450 | | | |<---------------1,JOIN--| | 451 | | | | | | | | 452 | |------------>x------------------2,Data->| | 453 | | | | | | | | | 454 | | | | | | | | | 455 +----------+ +--------|-+ +----------+ +----------+ 456 | 457 V 459 5.2 IGMP/MLD with L2 Authentication with ACL 461 With a basic implementation of IGMP/MLD implementation, no 462 authorization is performed on the receiver. It is possible to 463 combine an IGMP/MLD implementation with Layer 2 Authentication to 464 provide a control mechanism for accessing the network using 802.X. In 465 this scenario a receiver first requests to the L2 authentication 466 server for access to network. The authentication controller then 467 queries the policy server with the receiver's credentials (such as IP 468 or MAC address), and if the receiver is determined to be an 469 authorized user of the network ("success"), the router downloads the 470 ACL from the policy sever. For example, users which are not on the 471 ACL are rejected. Then the Layer 2 Switch is directed to open a port 472 for the receiver to send a join request to the multicast router. The 473 router is then responsible for forwarding the appropriate data from 474 the sender to the receiver. 476 Note: ACL is one of the methods to realize an access control policy. 477 Other methods exist. 479 +----------+ 480 | Policy | 481 | Server |\ 482 | | \ 483 +----------+ \ 4,ACL Download 484 | ^ \ 485 | | \ 486 V | V 487 +----------+ +----------+ +----------+ +----------+ 488 | L2 | | Router | | L2SW | | Receiver | 489 | | | | | | | | 490 | Auth. |<---------------------------- 1,Request-| | 491 | | | | | | | | 492 | |--------2,Success------------>X(3,Auth) | | 493 +----------+ | | | | | | 494 | | | | | | 495 +----------+ | | | | | | 496 | | | |<---------------5,Join---| | 497 | Sender | | | | | | | 498 | |------------>x------------------6,Data-->| | 499 | | | | | | | | | 500 +----------+ +--------|-+ +----------+ +----------+ 501 | 502 V 503 Key: 504 Auth: Authentication 506 5.3 Unicast Control with IGMP/MLD 508 The receiver first sends a unicast request to the sender, if 509 authorization is successful the sender sends the multicast address 510 information via unicast. With this multicast address the receiver 511 does a IGMP\MLD join as in described in 5.1. 512 +----------+ +----------+ +----------+ +----------+ 513 | Sender | | Router | | L2SW | | Receiver | 514 | | | | | | | | 515 | |<------------------------------1,Request-| | 516 | | | | | | | | 517 | |-------------------------------2,Success>| | 518 | | | | | | | | 519 | | | |<--------------3,Join----| | 520 | | | | | | | | 521 | |------------>x-----------------4,Data--->| | 522 | | | | | | | | | 523 | | | | | | | | | 524 +----------+ +--------|-+ +----------+ +----------+ 525 | 526 V 528 5.4 IGMP/MLD with Multicast Encryption 530 With a basic implementation of IGMP/MLD implementation, no data 531 protection is performed on data sent to the receiver. No credential 532 check is performed on the receiver and any receiver can receive and 533 use the data. The IGMP/MLD with Multicast Encryption model assumes 534 that the sender is sending encrypted data and that for this data to 535 be useful to the receiver it must first request and receive a key 536 from a group controller and key server that is synchronized with the 537 content encryption occurring on the sender's data. 539 +----------+ +----------+ +----------+ +----------+ 540 | G.C. & | | Router | | L2SW | | Receiver | 541 | | | | | | | | 542 | Key S. |<------------------------------1,Request-| | 543 | | | | | | | | 544 | |-------------------------------2,Key---->| | 545 +----------+ | | | | | | 546 | | | | | | 547 +----------+ | | | | | | 548 | | | |<---------------3,Join---| | 549 | Sender | | | | | | | 550 | |------------>x------------------4,Data-->| | 551 | | | | | | | | | 552 +----------+ +--------|-+ +----------+ +----------+ 553 | 554 V 555 Key: 556 G.C. & Key S.= Group Controller and Key Server 558 6. Evaluation of architectures by issue 560 In this section the various issues raised in section four are 561 analyzed by each of the architectures introduced in section five. 563 6.1 Access limit capabilities, compared by architecture 565 Comparison of currently available architectures with respect to 566 limiting the access of multicast groups 568 - IGMP/MLD: It is not possible to limit data reception. 570 - L2 authentication with ACL: 571 With an ACL it is possible to limit access of multicast groups. 572 However it should be discussed as to how scalable this approach is 573 because configuring an ACL could be a labor-intensive task. 575 - IGMP/MLD with Unicast control 576 It is possible for malicious users to reconfigure the receiver's 577 terminal to ignore the Unicast control. As such, this method may not 578 be strong enough to exclude ineligible accesses. 580 -Multicast Encryption: 581 It is possible for receivers to receive IP packets, even if they do 582 not possess the keys to decrypt them. A receiver may also be able to 583 store such received data until they discover a way to decrypt it. 584 Another disadvantage of this method is that network resources are 585 wasted if an ineligible receiver receives an encrypted content even 586 if they do not have a valid key. 588 6.2 Capability to distinguish between receivers, compared by 589 architecture 591 Comparison of currently available protocols. 593 -IGMP/MLD: 594 The sender has no direct line of contact with the receiver and 595 therefore cannot distinguish on a receiver-basis. (If the 596 interface is fixed to the receiver then the join-log can be used, but 597 this would mean portability is sacrificed. Moreover, this method is 598 not applicable to a case where the CSP and NSP are different 599 companies because CSP cannot access this join-log.) 601 -L2 authentication with ACL: 602 At the moment of L2 authentication it is possible to recognize 603 receivers, but if there are multiple content service providers (CSP) 604 a single L2 Authorization Server cannot distinguish among the CSPs. 605 Therefore it would be necessary to gather the join logs. (If the 606 interface is fixed then the join-log can be used, but this would mean 607 portability is sacrificed. Moreover, this method is not applicable 608 to a case where the CSP and NSP are different companies because the 609 CSP cannot access this join-log.) 611 -IGMP/MLD with Unicast control : 612 It is possible to distinguish among receivers using Unicast control. 614 -Multicast Encryption: 615 If the Content Service Provider maintains the Key Server it is 616 possible to distinguish on the receiver-level. If the Network 617 Service Provider maintains the key server it is necessary to devise a 618 method for the NSP to notify the CSP. 620 6.3 Capability to distinguish between users, compared by architecture 622 Comparison of currently available protocols: 624 -IGMP/MLD: 625 Since there is no user-based information, it is not possible to 626 distinguish on the user-level. 628 -L2 authentication with ACL: 629 At the moment of L2 Authentication it is possible to distinguish on 630 the user-level. 632 However it is difficult to combine user and group logs: it would be 633 necessary to match user IDs from L2-Auth logs and group IDs from the 634 Join logs to match users and groups. 636 -IGMP/MLD with unicast control : 637 Distinguishing by user is possible using unicast control. 639 -Multicast Encryption: 640 If the Content Provider manages the Key Server it is possible to 641 distinguish the user. 642 If the Network Service Provider manages the Key Server it is 643 necessary to notify the Content Provider. 645 6.4 Maintain guaranteed quality-level of data delivery (Voice, Video), 646 compared by architecture 648 Comparison of currently available protocols: 650 -IGMP/MLD: 651 It is not possible to reject a user attempting to access even if 652 there are not sufficient resources. 654 -L2 authentication with ACL: 655 The AAA server does not know whether there are sufficient resources 656 or not. While it is possible to control QoS levels on a link-by-link 657 basis, it is not possible on a service-by-service basis. 659 -IGMP/MLD with Unicast control : 660 When the CSP and NSP are separate entities it is not possible for the 661 CSP to make a proper authorization decision because only the NSP 662 grasps the network resource availability. 664 -Multicast Encryption: 665 It is not possible to reject a user attempting to access even if 666 there are not sufficient resources because the user can receive data 667 even without a valid key. 669 6.5 Fast leave for fast surfing capability, compared by architecture 671 Comparison of currently available protocols: 673 -IGMP/MLD: 674 It is possible to track on a per host level (based on host address) 675 therefore fast leave for fast surfing capability can be achieved. 677 -L2 authentication with ACL: 679 It is possible to track on a per host level (based on host address) 680 therefore fast leave for fast surfing capability can be achieved. 682 -IGMP/MLD with Unicast control : 683 Even if a quick leave is possible, changing to a new channel using 684 Unicast Control is slow (latency problem). 686 -Multicast Encryption: 687 Even if a quick leave is possible, delivery of the Key Exchange 688 Identifier(KEI) is slow. 690 6.6 Surveillance of receiver by sender, compared by architecture 692 Comparison of currently available protocols: 694 -IGMP/MLD: 695 With this protocol it is possible to log separately join and leave 696 actions, but it is difficult to match these join and leave actions 697 when analyzing the logs is heavy computation (scalability with 698 millions of users). 700 -L2 authentication with ACL: 701 In this protocol the leave action is not recorded. 703 -IGMP/MLD with Unicast control : 704 In this solution the leave action is not recorded. 706 -Multicast Encryption: 707 If logs are recorded for each renewal of keys, then it is possible to 708 track activity on a per-user basis. However if logs are only recorded 709 per content data download then such tracking is not possible. 711 6.7.Notification to users of the result of the join request compared by 712 architecture 714 Comparison of currently available protocols: 716 -IGMP/MLD: 717 After the join it is not possible to notify the user of the result of 718 the join request. 720 -L2 authentication with ACL: 721 After the join it is not possible to notify the user of the result of 722 the join request. 724 -IGMP/MLD with Unicast control : 725 After the join it is not possible to notify the user of the result of 726 the join request. 728 -Multicast Encryption: 729 After the join it is not possible to notify the user of the result of 730 the join request. 732 6.8 Triple Play capability, compared by architecture 734 Comparison of currently available protocols: 736 -IGMP/MLD: 737 It is necessary for NSP to integrate all "triple play services" into 738 a single access control system. No standards currently exist. 740 -L2 authentication with ACL: 742 When services have a per-channel fee structure that require real-time 743 changes to the access control list (such as prepayment for specific 744 shows), it is not possible to integrate these services with other 745 services. On the other hand for a fixed subscription based service 746 where the access control list is not changed, it is possible to 747 integrate the triple-play services on one infrastructure. 749 -IGMP/MLD with Unicast control : 750 It is necessary for NSP to integrate all "triple play services" into 751 a single access control system. No standards currently exist. 753 -Multicast Encryption: 754 It is necessary for NSP to integrate all "triple play services" into 755 a single access control system. No standards currently exist. 757 7. IANA considerations 759 This I-D does not raise any IANA consideration issues. 761 8. Security considerations 763 This I-D does not raise any new security issues which are not already 764 existing in original protocols. Enhancement of multicast access 765 control capabilities may enhance security performance. 767 9. Conclusion 769 Issues such as user identification, access-control, tracking and 770 billing are common requirements for many content delivery services 771 (CDS) systems. When CDS systems employ multicasting with 772 architectures based on currently existing multicasting standards, it 773 is often necessary to deploy non-standardized solutions to meet these 774 common requirements. It is recommended that requirements be defined 775 to serve as a basis for creating standardized ways to address the 776 various issues discussed in this I-D which are limiting the 777 application of multicasting especially to commercial, large-scale CDS 778 services. Such requirements should take into consideration a range of 779 possible architectures based on multiple business or usage models. 781 Normative References 783 [1] B. Cain, et. al., "Internet Group Management Protocol, Version 3", 784 RFC3376, October 2002. 786 [2] R. Vida, et. al., "Multicast Listener Discovery Version 2 (MLDv2) 787 for IPv6", RFC3810, June 2004. 789 Authors' Addresses 791 Tsunemasa Hayashi 792 NTT Network Innovation Laboratories 793 1-1 Hikari-no-oka, Yokosuka-shi, Kanagawa, 239-0847 Japan 794 Phone: +81 46 859 8790 795 Email: hayashi.tsunemasa@lab.ntt.co.jp 797 Haixiang He 798 Nortel Networks 799 600 Technology Park Drive 800 Billerica, MA 01801, USA 801 Phone: +1 978 288 7482 802 Email: haixiang@nortelnetworks.com 804 Hiroaki Satou 805 NTT Network Service Systems Laboratories 806 3-9-11 Midoricho, Musashino-shi, Tokyo, 180-8585 Japan 807 Phone : +81 422 59 4683 808 Email : satou.hiroaki@lab.ntt.co.jp 810 Hiroshi Ohta 811 NTT Network Service Systems Laboratories 812 3-9-11 Midoricho, Musashino-shi, Tokyo, 180-8585 Japan 813 Phone : +81 422 59 3617 814 Email: ohta.hiroshi@lab.ntt.co.jp 816 Susheela Vaidya 817 Cisco Systems, Inc. 818 170 W. Tasman Drive 819 San Jose, CA 95134 820 Phone: +1-408-525-1952 821 Email: svaidya@cisco.com 823 Full Copyright Statement 825 Copyright (C) The Internet Society (2004). 827 This document is subject to the rights, licenses and restrictions 828 contained in BCP 78, and except as set forth therein, the authors 829 retain all their rights. 831 This document and the information contained herein are provided on an 832 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 833 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 834 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 835 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 836 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 837 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 839 Intellectual Property 841 The IETF takes no position regarding the validity or scope of any 842 Intellectual Property Rights or other rights that might be claimed to 843 pertain to the implementation or use of the technology described in 844 this document or the extent to which any license under such rights 845 might or might not be available; nor does it represent that it has 846 made any independent effort to identify any such rights. Information 847 on the IETF's procedures with respect to rights in IETF Documents can 848 be found in BCP 78 and BCP 79. 850 Copies of IPR disclosures made to the IETF Secretariat and any 851 assurances of licenses to be made available, or the result of an 852 attempt made to obtain a general license or permission for the use of 853 such proprietary rights by implementers or users of this 854 specification can be obtained from the IETF on-line IPR repository at 855 http://www.ietf.org/ipr. 857 The IETF invites any interested party to bring to its attention any 858 copyrights, patents or patent applications, or other proprietary 859 rights that may cover technology that may be required to implement 860 this standard. Please address the information to the IETF at ietf 861 ipr@ietf.org. 863 Acknowledgement 865 Funding for the RFC Editor function is currently provided by the 866 Internet Society.