idnits 2.17.1 draft-ietf-mboned-rac-issues-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 755. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 773. ** 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? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 4 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 == Line 26 has weird spacing: '...obsolet ed by...' -- 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 (October 12, 2005) is 6772 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-01 ** Downref: Normative reference to an Informational draft: draft-ietf-mboned-maccnt-req (ref. '3') Summary: 8 errors (**), 0 flaws (~~), 5 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: April 15, 2006 Hiroaki Satou, NTT 5 Hiroshi Ohta, NTT 6 Susheela Vaidya, Cisco Systems 8 October 12, 2005 10 Issues Related to Receiver Access Control in the Current Multicast 11 Protocols 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 obsolet ed by other documents at 27 any 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 April 15, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005) 42 Abstract 44 This I-D evaluates the extent to which current multicasting protocols 45 can be used to address common requirements for commercial, large- 46 scale IP multicasting. Four existing possible multicasting 47 architectures (with or without some form of access or content 48 control) are presented. Then each architecture is analyzed with 49 respect to how it can or cannot satisfactorily address each issue. 50 This I-D concludes that for many of these issues the possible 51 architectures based on present standards as they now exist require 52 non-standardized solutions to meet common use requirements. This I-D 53 recommends for requirements to be defined that would set the 54 groundwork for creating standardized ways to overcome these 55 limitations. 57 Copyright Notice...................................................1 58 1. Introduction....................................................3 59 2. Definitions and Abbreviations...................................4 60 2.1 Definitions....................................................4 61 2.2 Abbreviations..................................................4 62 3. Common use models and network architecture implications.........5 63 4. Issues in multicasting related to commercial and large-scale 64 implementations....................................................6 65 4.1 Access limits and resource issues..............................6 66 4.2 Capability to distinguish between receivers (end hosts)........6 67 4.3 Capability to distinguish between users (as opposed to merely 68 hosts).............................................................7 69 4.4 Channel "leave latency"........................................7 70 4.5 Surveillance of receiver by sender.............................7 71 4.5.1 Precise access log...........................................7 72 4.5.2 How to share user information................................7 73 4.5.3 Trustworthy logs to monitor user activity....................8 74 4.6 Notification to users of the result of the join request........8 75 4.7 Triple Play....................................................8 76 4.8 DRM Protection.................................................8 77 5. Description of existing architectures...........................8 78 5.1 IGMP/MLD.......................................................8 79 5.2 IGMP/MLD plus L2/L3 Authentication with Access Control Policy.10 80 5.3 Unicast Control with IGMP/MLD.................................11 81 5.4 IGMP/MLD with Multicast Encryption............................11 82 6. Evaluation of architectures by issue...........................12 83 6.1 Access limit capabilities, compared by architecture...........12 84 6.2 Capability to distinguish between receivers, compared by 85 architecture......................................................13 86 6.3 Capability to distinguish between users, compared by architecture 87 ..................................................................13 88 6.4 Maintain guaranteed quality-level of data delivery (Voice, Video), 89 compared by architecture..........................................14 90 6.5 Fast leave for fast surfing capability, compared by architecture 91 ..................................................................14 92 6.6 Surveillance of receiver by sender, compared by architecture..15 93 6.7.Notification to users of the result of the join request compared 94 by architecture...................................................15 95 6.8 Comparison summary............................................16 96 7. IANA considerations............................................16 97 8. Security considerations........................................16 98 9. Conclusion.....................................................16 99 Normative References..............................................17 100 Full Copyright Statement..........................................19 101 Intellectual Property.............................................19 102 Acknowledgement...................................................19 104 1. Introduction 106 The intention of this I-D is to initiate a discussion on the state of 107 current multicasting protocols deployed for commercial, large-scale 108 multicasting and their capabilities to provide receiver access 109 control. 111 Existing IP multicasting protocols (as presented in Section 5) were 112 designed to meet certain sets of requirements that do not necessarily 113 include architectural considerations intended to support commercial 114 services. This I-D presents a number of issues network providers may 115 face when they attempt to apply current multicasting standards to 116 commercial services. The extent to which existing multicast 117 protocols can or cannot satisfactorily deal with these issues is 118 explored. A few network models based on a range of different 119 business models are presented as a basis for defining requirements. 121 Multicasting can be useful to make the network more scalable when a 122 large volume of information needs to be distributed to a large number 123 of receivers. However, multicasting according to current standards 124 (e.g., IGMPv3[1] and MLDv2[2]) has drawbacks compared to unicasting 125 in terms of its commercial applicability because of the insufficiency 126 of access control and protect network resources against malicious use 127 or accidents. In order to be applicable to large-scale commercial 128 networks, multicast networks need to have the same capabilities which 129 are currently supported by unicast networks. Such issues which are 130 important to commercial, large-scale implementations of multicasting 131 are listed. Next, a few possible existing architectures used for 132 multicasting with access control based on current standards are 133 presented. Specifically 1) IGMP/ MLD, 2) IGMP/MLD with L2 134 Authentication with ACL 3) Unicast Control with IGMP/MLD and 4) 135 IGMP/MLD with Multicast Encryption will each be presented and 136 described. Each architecture is discussed with respect to the 137 presented list of issues. 139 2. Definitions and Abbreviations 141 2.1 Definitions 143 For the purposes of this I-D the following definitions apply: 145 Accounting: actions for grasping each user's behavior, when she/he 146 starts/stops to receive a channel, which channel she/he receives, etc. 148 Authentication: action for identifying a user as a genuine one. 150 Authorization: action for giving permission to access the content or 151 network to a user. 153 Receiver: an end-host or end-client which receives content. A 154 receiver may be distinguishable by a network ID such as MAC address 155 or IP address. 157 User: a human with a user account. A user may possibly use multiple 158 reception devices. Multiple users may use the same reception device. 160 Note: The definition of a receiver (device) and a user (human) should 161 not be confused. 163 2.2 Abbreviations 165 For the purposes of this draft the following abbreviations apply: 167 ACL: Access Control List 169 CDS: Content Delivery Services 171 CSP: Content Service Provider 173 DRM: Data Rights Management 175 KEI: Key Exchange Identifier 177 NSP: Network Service Provider 178 QoS: Quality of Service 180 3. Common use models and network architecture implications 182 Issues such as user identification, access-control, tracking and 183 billing are common requirements for commercial content delivery 184 services (CDS) systems (and are important in many non-commercial CDS 185 systems as well.) These same requirements should be met for CDS 186 systems that employ multicasting. 188 In some cases a single entity may design and be responsible for a 189 system that covers the various common high-level requirements of a 190 commercial multicasting system such as 1) content serving, 2) the 191 infrastructure to multicast it, 3) network and content access control 192 mechanisms. In many cases however the content provision and network 193 provision roles are divided between separate entities. The I-D 194 draft-ietf-mboned-maccnt-00.txt provides more detail of the multiple 195 versus single entity CDS network model. 197 As such it should not be assumed that the entity responsible for the 198 multicasting structure and the entity responsible for content serving 199 are the same. Indeed because the infrastructure for multicasting is 200 expensive and many content holders are not likely to be competent at 201 building and maintaining complicated infrastructures necessary for 202 multicasting, many content holders would prefer to purchase transport 203 and management services from a network service provider and thus 204 share the infrastructure costs with other content holders. 206 Similarly commercial network service providers do not generally 207 specialize in providing content and are unlikely to build and 208 maintain such a resource-intensive system without a certain level of 209 demand from content holders. 211 The business model of a single NSP providing multicasting services to 212 multiple CSP has certain implications: 214 -Need for user tracking and billing capabilities 215 -Need for network access control and/or content access control 216 satisfactory to the requirements of the CSP 217 -Methods for sharing information between the NSP and CSP to make 218 the above two possible 220 When the NSP and CSP are the same single entity the general 221 requirements are as follows. 223 -Need for user tracking and user-billing capabilities 224 -Need for access control and/or content protection at level the 225 entity deems appropriate 227 In the next section issues in multicasting related to commercial and 228 large-scale implementations are presented. Some presented issues are 229 not pertinent to cases where the NSP and CSP are the same entity. 231 4. Issues in multicasting related to commercial and large-scale 232 implementations 234 This section lists issues related to receiver access control in 235 current multicasting protocols which are especially important to 236 commercial, large-scale multicasting. More details concerning the 237 requirements related to these issues are provided in a separate I-D 238 draft-ietf-mboned-maccnt-00.txt[3]. References to that document are 239 provided as applicable below. 241 4.1 Access limits and resource issues 243 For commercial applications of multicasting, network and content 244 providers generally wish to be able to control the number of groups a 245 host can access at the same time. Also the network provider may wish 246 to limit the number of users accessing a multicast stream because of 247 bandwidth and processing issues between the receiver and the 248 multicast server. 250 With best-effort services (e.g. mail transfer, web surfing) strict 251 network resource allocation is not necessary, but for services with a 252 guaranteed QoS level (e.g. IP television, teleconferencing, VoIP) it 253 is necessary to allocate sufficient bandwidth and server resources to 254 each service. In order to guarantee certain QoS levels, it is 255 important for network providers to be able to protect their network 256 resources from being wasted (either maliciously or accidentally). 258 More detail on this topic is provided in I-D draft-ietf-mboned- 259 maccnt-00.txt, section "Issue of network resource protection." 261 4.2 Capability to distinguish between receivers (end hosts) 263 Currently the sender cannot distinguish which receivers (end hosts) 264 are actually receiving its information with existing protocols 265 (IGMP/MLD.) The sender must rely on the information from the 266 multicasting routers. This can be complicated if the sender and 267 routers are maintained by different entities. There is currently no 268 standard way to share such information. 270 4.3 Capability to distinguish between users (as opposed to merely 271 hosts) 273 Many content providers would like to have detailed information on 274 which users (as opposed to merely hosts identified by physical 275 addresses, etc.) are consuming their content and information on 276 their usage behavior. More detail on this topic can be found in I-D 277 draft-ietf-mboned-maccnt-00.txt, section "User identification." 279 4.4 Channel "leave latency" 281 Commercial implementations of IP multicasting are likely to have 282 strict requirements in terms of user experience. Leave latency is 283 the time between when a user sends a signal that he/she wishes to 284 "leave" a group and when the network recognizes the "leave." 285 A separate I-D draft-ietf-mboned-maccnt-00.txt provides more detail 286 on this topic in the section "Channel 'leave latency'" 288 4.5 Surveillance of receiver by sender 290 4.5.1 Precise access log 292 It is necessary to precisely log information such as who (host/user) 293 is accessing what content at from what time (join action) until what 294 time (leave action). The result of the access-control decision (e.g. 295 results of authorization) would also be valuable information. 297 4.5.2 How to share user information 299 For commercial multicast applications where NSP and CSP are different 300 entities, there are a number of issues regarding how to share user 301 information between the NSP and CSP. For example, which entities 302 should be able to access which information relating to user-based 303 tracking? What is the user identifier that can be used between the 304 entities to distinguish among users, and which entities should be 305 able to recognize this identifier? Another important issue is how 306 the edge router should be able to access and then maintain user 307 information. The current situation of present architectures is that 308 only the NSP can get information about user activity, because user 309 activities are only observable from join/leave information logged on 310 edge devices which are under control of the NSP. 312 4.5.3 Trustworthy logs to monitor user activity 314 An important issue for commercial multicasting applications is how 315 the NSP can get trustworthy data on user activity which may be needed 316 for billing and statistics purposes. A standard way of logging user 317 activity and protecting the integrity of the logs does not exist. 318 Often network providers do not want to keep logs on untrusted user 319 terminals which can be tampered with. 321 4.6 Notification to users of the result of the join request 323 It is necessary to provide information to the user about the status 324 of his/her join request(granted/denied/other). 326 4.7 Triple Play 328 Ideally the NSP should be able to use the same infrastructure (such 329 as access control) to support commercial multicast services for the 330 so-called "triple play" services: voice (VoIP), video, and broadband 331 Internet access services. 333 4.8 DRM Protection 335 Digital Rights Management (DRM) is important but out of scope of this 336 I-D. 338 5. Description of existing architectures 340 In this section, existing architectures used for multicasting based 341 on current standards are defined. In section 6 these architectures 342 will be compared by the issues presented in section 4. 344 5.1 IGMP/MLD 346 Internet Group Management Protocol(IGMP) or Multicast Listener 347 Discovery (MLD) are protocols for layer 3 management of multicasting. 348 In IP multicast a receiver sends a request to a first-hop multicast 349 router to join a particular multicast group. The router is then 350 responsible for forwarding the appropriate data from the sender to 351 the receiver. 353 +----------+ +----------+ +----------+ +----------+ 354 | Sender | | Router | | L2SW | | Receiver | 355 | | | |<---------------1,JOIN--| | 356 | | | | | | | | 357 | |--------------------------------2,Data->| | 358 | | | | | | | | 359 | | | | | | | | 360 +----------+ +----------+ +----------+ +----------+ 362 For the sake of simplicity, the above diagram only shows the sequence 363 of requests for a single receiver. When multiple receivers are 364 requesting the same channel stream the data would be copied at the 365 multicasting router to serve the multiple streams. 367 5.2 IGMP/MLD plus L2/L3 Authentication with Access Control Policy 369 With a basic implementation of IGMP/MLD implementation, no 370 authorization is performed on the receiver. It is possible to 371 combine an IGMP/MLD implementation with Layer 2 or Layer 3 372 Authentication to provide an access-control mechanism at the first 373 point of attachment to the network, for example, using 802.X. 375 For example, a receiver may request to an L2 authentication server 376 for access to the network. The authentication controller then queries 377 the policy server with the receiver's credentials (such as IP or MAC 378 address), and if the receiver is determined to be an authorized user 379 of the network ("success"), the router downloads the ACL from the 380 policy sever. For example, users which are not on the ACL are 381 rejected. Then the Layer 2 Switch is directed to open a port for the 382 receiver to send a join request to the multicast router. The router 383 is then responsible for forwarding the appropriate data from the 384 sender to the receiver. 386 Note: ACL is one existing method to realize an access control policy. 387 Other methods exist. 389 +----------+ 390 | Policy | 391 | Server |\ 392 | | \ 393 +----------+ \ 4,ACL Download 394 | ^ \ 395 | | \ 396 V | V 397 +----------+ +----------+ +----------+ +----------+ 398 | L2 | | Router | | L2SW | | Receiver | 399 | | | | | | | | 400 | Auth. |<---------------------------- 1,Request-| | 401 | | | | | | | | 402 | |--------2,Success------------>X(3,Auth) | | 403 +----------+ | | | | | | 404 | | | | | | 405 +----------+ | | | | | | 406 | | | |<---------------5,Join---| | 407 | Sender | | | | | | | 408 | |------------>x------------------6,Data-->| | 409 | | | | | | | | | 410 +----------+ +--------|-+ +----------+ +----------+ 411 | 412 V 413 Key: 414 Auth: Authentication 416 5.3 Unicast Control with IGMP/MLD 418 The receiver first sends a unicast request to the sender which 419 resides in the CP's domain. This method is the same as that used in 420 unicast video-on �demand (VoD) systems. If authorization is 421 successful the sender sends the multicast address information via 422 unicast. With this multicast address the receiver does a IGMP\MLD 423 join as in described in 5.1. 424 +----------+ +----------+ +----------+ +----------+ 425 | Sender | | Router | | L2SW | | Receiver | 426 | | | | | | | | 427 | |<------------------------------1,Request-| | 428 | | | | | | | | 429 | |-------------------------------2,Success>| | 430 | | | | | | | | 431 | | | |<--------------3,Join----| | 432 | | | | | | | | 433 | |------------>x-----------------4,Data--->| | 434 | | | | | | | | | 435 | | | | | | | | | 436 +----------+ +--------|-+ +----------+ +----------+ 437 | 438 V 440 5.4 IGMP/MLD with Multicast Encryption 442 With a basic implementation of IGMP/MLD, no data protection is 443 performed on data sent to the receiver. No credential check is 444 performed on the receiver and any receiver can receive and use the 445 data. The IGMP/MLD with Multicast Encryption model assumes that the 446 sender is sending encrypted data and that for this data to be useful 447 to the receiver it must first request and receive a key from a group 448 controller and key server that is synchronized with the content 449 encryption occurring on the sender's data. 451 +----------+ +----------+ +----------+ +----------+ 452 | G.C. & | | Router | | L2SW | | Receiver | 453 | | | | | | | | 454 | Key S. |<------------------------------1,Request-| | 455 | | | | | | | | 456 | |-------------------------------2,Key---->| | 457 +----------+ | | | | | | 458 | | | | | | 459 +----------+ | | | | | | 460 | | | |<---------------3,Join---| | 461 | Sender | | | | | | | 462 | |------------>x------------------4,Data-->| | 463 | | | | | | | | | 464 +----------+ +--------|-+ +----------+ +----------+ 465 | 466 V 467 Key: 468 G.C. & Key S.= Group Controller and Key Server 470 6. Evaluation of architectures by issue 472 In this section the various issues raised in section four are 473 analyzed by each of the architectures introduced in section five. 475 6.1 Access limit capabilities, compared by architecture 477 Comparison of currently available architectures with respect to 478 limiting the access of multicast groups 480 - IGMP/MLD: It is not possible to limit data reception. 482 - L2/L3 authentication with access control policy: 483 With an ACL it is possible to limit access of multicast groups. 484 However it should be discussed as to how scalable this approach is 485 because configuring an ACL could be a labor-intensive task. 487 - IGMP/MLD with Unicast control 488 It is possible for malicious users to reconfigure the receiver's 489 terminal to ignore the Unicast control. In this case, this 490 maliciously reconfigured terminal could send a join message even if 491 it is rejected by the network. In such a case, the ineligible 492 receiver would be able to receive the multicast. As such, this 493 method may not be strong enough to exclude ineligible access. 495 -Multicast Encryption: 496 It is possible for receivers to receive IP packets, even if they do 497 not possess the keys to decrypt them. A receiver may also be able to 498 store such received data until they discover a way to decrypt it. 499 Another disadvantage of this method is that network resources are 500 wasted if an ineligible receiver receives an encrypted content even 501 if they do not have a valid key. 503 6.2 Capability to distinguish between receivers, compared by 504 architecture 506 Comparison of currently possible protocol-based solutions. 508 -IGMP/MLD: 509 The sender has no direct line of contact with the receiver and 510 therefore cannot distinguish on a receiver-basis. (If the 511 interface is fixed to the receiver then the join-log can be used, but 512 this would mean portability is sacrificed. Moreover, this method is 513 not applicable to a case where the CSP and NSP are different 514 companies because CSP cannot access this join-log.) 516 -L2/L3 authentication with access control policy: 517 At the moment of L2/L3 authentication it is possible to recognize 518 receivers, but if there are multiple content service providers (CSP) 519 a single L2 Authorization Server cannot distinguish among the CSPs. 520 Therefore it would be necessary to gather the join logs. (If the 521 interface is fixed then the join-log can be used, but this would mean 522 portability is sacrificed. Moreover, this method is not applicable 523 to a case where the CSP and NSP are different companies because the 524 CSP cannot access this join-log.) 526 -IGMP/MLD with Unicast control : 527 It is possible to distinguish among receivers using Unicast control. 529 -Multicast Encryption: 530 If the Content Service Provider maintains the Key Server it is 531 possible to distinguish on the receiver-level. If the Network 532 Service Provider maintains the key server it is necessary to devise a 533 method for the NSP to notify the CSP. 535 6.3 Capability to distinguish between users, compared by architecture 537 Comparison of currently possible protocol-based solutions: 539 -IGMP/MLD: 540 Since there is no user-based information, it is not possible to 541 distinguish on the user-level. 543 -L2/L3 authentication with access control policy: 544 At the moment of L2/L3 Authentication it is possible to distinguish 545 on the user-level. 547 However it is difficult to combine user and group logs: it would be 548 necessary to match user IDs from L2-Auth logs and group IDs from the 549 Join logs to match users and groups. 551 -IGMP/MLD with unicast control : 552 Distinguishing by user is possible using unicast control. 554 -Multicast Encryption: 555 If the Content Provider manages the Key Server it is possible to 556 distinguish the user. 557 If the Network Service Provider manages the Key Server it is 558 necessary to notify the Content Provider. 560 6.4 Maintain guaranteed quality-level of data delivery (Voice, Video), 561 compared by architecture 563 Comparison of currently possible protocol-based solutions: 565 -IGMP/MLD: 566 It is not possible to reject a user attempting to access even if 567 there are not sufficient resources. 569 -L2/L3 authentication with access control policy: 570 The AAA server does not know whether there are sufficient resources 571 or not. This method still can provide a guaranteed QoS if every 572 channel has the same bandwidth and sufficient bandwidth are allocated 573 to each user beforehand. However, it is not possible to provide a 574 guaranteed QoS by comparing the available bandwidth and the necessary 575 bandwidth upon each user's request. 577 -IGMP/MLD with Unicast control : 578 When the CSP and NSP are separate entities it is not possible for the 579 CSP to make a proper authorization decision because only the NSP 580 grasps the network resource availability. 582 -Multicast Encryption: 583 It is not possible to reject a user attempting to access even if 584 there are not sufficient resources because the user can receive data 585 even without a valid key. 587 6.5 Fast leave for fast surfing capability, compared by architecture 589 Comparison of currently possible protocol-based solutions: 591 -IGMP/MLD: 592 It is possible to track on a per host level (based on host address) 593 therefore fast leave for fast surfing capability can be achieved. 595 -L2/L3 authentication with access control policy: 596 It is possible to track on a per host level (based on host address) 597 therefore fast leave for fast surfing capability can be achieved. 599 -IGMP/MLD with Unicast control : 600 Even if a quick leave is possible, changing to a new channel using 601 Unicast Control is slow (latency problem). 603 -Multicast Encryption: 604 Even if a quick leave is possible, delivery of the Key Exchange 605 Identifier(KEI) is slow. 607 6.6 Surveillance of receiver by sender, compared by architecture 609 Comparison of currently possible protocol-based solutions: 611 -IGMP/MLD: 612 With this protocol it is possible to separately log join and leave 613 actions, but it is difficult to match these join and leave actions 614 because analyzing the logs requires heavy computation (related to the 615 scalability with millions of users). 617 -L2/L3 authentication with access control policy: 618 In this solution, the leave action is not recorded unless some 619 additional mechanism such as IGMP/MLD snooping is used. In some 620 cases, users disconnect their terminals without sending leave 621 messages. In this case, it is not possible to determine when each 622 user's entry in the ACL should be deactivated. 624 -IGMP/MLD with Unicast control : 625 In this solution the leave action is not recorded. 627 -Multicast Encryption: 628 If logs are recorded for each renewal of keys, then it is possible to 629 track activity on a per-user basis. However if logs are only recorded 630 per content data download then such tracking is not possible. 632 It should be noted that authentication of the source of each 633 join/leave message is important. 635 6.7.Notification to users of the result of the join request compared by 636 architecture 638 Comparison of currently possible protocol-based solutions: 640 -IGMP/MLD: 641 After the join it is not possible to notify the user of the result of 642 the join request. 644 -L2/L3 authentication with access control policy: 645 After the join it is not possible to notify the user of the result of 646 the join request. 648 -IGMP/MLD with Unicast control : 649 After the join it is not possible to notify the user of the result of 650 the join request. 652 -Multicast Encryption: 653 After the join it is not possible to notify the user of the result of 654 the join request. 656 6.8 Comparison summary 658 In this section a variety of existing architectures used for 659 multicasting based on current standards were compared and evaluated. 660 None of these architectures can sufficiently meet all of the common 661 requirements for accounting, authentication and authorization in 662 commercial, large-scale IP multicasting. Therefore it is recommended 663 that framework(s) for sufficiently addressing such requirements be 664 explored. 666 7. IANA considerations 668 This I-D does not raise any IANA consideration issues. 670 8. Security considerations 672 This I-D does not raise any new security issues which are not already 673 existing in original protocols. Enhancement of multicast access 674 control capabilities may enhance security performance. 676 9. Conclusion 678 Issues such as user identification, access-control, tracking and 679 billing are common requirements for many content delivery services 680 (CDS) systems. When CDS systems employ multicasting with 681 architectures based on currently existing multicasting standards, it 682 is often necessary to deploy non-standardized solutions to meet these 683 common requirements. It is recommended that requirements be defined 684 to serve as a basis for creating standardized ways to address the 685 various issues discussed in this I-D which are limiting the 686 application of multicasting especially to commercial, large-scale CDS 687 services. Such requirements should take into consideration a range of 688 possible architectures based on multiple business or usage models. 690 Normative References 692 [1] B. Cain, et. al., "Internet Group Management Protocol, Version 3", 693 RFC3376, October 2002. 695 [2] R. Vida, et. al., "Multicast Listener Discovery Version 2 (MLDv2) 696 for IPv6", RFC3810, June 2004. 698 [3] Hayashi, et. al., "Accounting, Authentication and Authorization 699 Issues in Well Managed IP Multicasting Services", draft-ietf- 700 mboned-maccnt-req-01.txt, October 2005 [Work in Progress]. 702 Authors' Addresses 704 Tsunemasa Hayashi 705 NTT Network Innovation Laboratories 706 1-1 Hikari-no-oka, Yokosuka-shi, Kanagawa, 239-0847 Japan 707 Phone: +81 46 859 8790 708 Email: hayashi.tsunemasa@lab.ntt.co.jp 710 Haixiang He 711 Nortel Networks 712 600 Technology Park Drive 713 Billerica, MA 01801, USA 714 Phone: +1 978 288 7482 715 Email: haixiang@nortelnetworks.com 717 Hiroaki Satou 718 NTT Network Service Systems Laboratories 719 3-9-11 Midoricho, Musashino-shi, Tokyo, 180-8585 Japan 720 Phone : +81 422 59 4683 721 Email : satou.hiroaki@lab.ntt.co.jp 723 Hiroshi Ohta 724 NTT Network Service Systems Laboratories 725 3-9-11 Midoricho, Musashino-shi, Tokyo, 180-8585 Japan 726 Phone : +81 422 59 3617 727 Email: ohta.hiroshi@lab.ntt.co.jp 729 Susheela Vaidya 730 Cisco Systems, Inc. 731 170 W. Tasman Drive 732 San Jose, CA 95134 733 Phone: +1-408-525-1952 734 Email: svaidya@cisco.com 736 Comments 738 Comments are solicited and should be addressed to the mboned working 739 group's mailing list at mboned@lists.uoregon.edu_and/or the authors. 741 Full Copyright Statement 743 Copyright (C) The Internet Society (2005). 745 This document is subject to the rights, licenses and restrictions 746 contained in BCP 78, and except as set forth therein, the authors 747 retain all their rights. 749 This document and the information contained herein are provided on an 750 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 751 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 752 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 753 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 754 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 755 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 757 Intellectual Property 759 The IETF takes no position regarding the validity or scope of any 760 Intellectual Property Rights or other rights that might be claimed to 761 pertain to the implementation or use of the technology described in 762 this document or the extent to which any license under such rights 763 might or might not be available; nor does it represent that it has 764 made any independent effort to identify any such rights. Information 765 on the IETF's procedures with respect to rights in IETF Documents can 766 be found in BCP 78 and BCP 79. 768 Copies of IPR disclosures made to the IETF Secretariat and any 769 assurances of licenses to be made available, or the result of an 770 attempt made to obtain a general license or permission for the use of 771 such proprietary rights by implementers or users of this 772 specification can be obtained from the IETF on-line IPR repository at 773 http://www.ietf.org/ipr. 775 The IETF invites any interested party to bring to its attention any 776 copyrights, patents or patent applications, or other proprietary 777 rights that may cover technology that may be required to implement 778 this standard. Please address the information to the IETF at ietf 779 ipr@ietf.org. 781 Expiration 783 This Internet-Draft will expire on April 15, 2006. 785 Acknowledgement 787 Funding for the RFC Editor function is currently provided by the 788 Internet Society.