idnits 2.17.1 draft-ietf-mboned-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 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 760. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 778. ** 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: ---------------------------------------------------------------------------- == 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 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.) -- The document date (July 4, 2005) is 6863 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-00 ** Downref: Normative reference to an Informational draft: draft-ietf-mboned-maccnt-req (ref. '3') Summary: 7 errors (**), 0 flaws (~~), 4 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: January 4, 2006 Hiroaki Satou, NTT 5 Hiroshi Ohta, NTT 6 Susheela Vaidya, Cisco Systems 8 July 4, 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 obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on January 4, 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..9 80 5.3 Unicast Control with IGMP/MLD.................................10 81 5.4 IGMP/MLD with Multicast Encryption............................11 82 6. Evaluation of architectures by issue...........................11 83 6.1 Access limit capabilities, compared by architecture...........11 84 6.2 Capability to distinguish between receivers, compared by 85 architecture..................................................12 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......................................13 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..14 93 6.7.Notification to users of the result of the join request compared 94 by architecture...............................................15 95 6.8 Comparison summary............................................15 96 7. IANA considerations............................................15 97 8. Security considerations........................................16 98 9. Conclusion.....................................................16 99 Normative References..............................................16 100 Comments..........................................................17 101 Full Copyright Statement..........................................18 102 Intellectual Property.............................................18 103 Expiration........................................................18 104 Acknowledgement...................................................18 106 1. Introduction 108 The intention of this I-D is to initiate a discussion on the state of 109 current multicasting protocols deployed for commercial, large-scale 110 multicasting and their capabilities to provide receiver access 111 control. 113 Existing IP multicasting protocols (as presented in Section 5) were 114 designed to meet certain sets of requirements that do not necessarily 115 include architectural considerations intended to support commercial 116 services. This I-D presents a number of issues network providers may 117 face when they attempt to apply current multicasting standards to 118 commercial services. The extent to which existing multicast 119 protocols can or cannot satisfactorily deal with issue is explored. 120 A few network models based on a range of different business models 121 are presented as a basis for defining requirements. 123 Multicasting can be useful to make the network more scalable when a 124 large volume of information needs to be distributed to a large number 125 of receivers. However, multicasting according to current standards 126 (e.g., IGMPv3[1] and MLDv2[2]) has drawbacks compared to unicasting 127 in terms of its commercial applicability because of the insufficiency 128 of access control and protect network resources against malicious use 129 or accidents. In order to be applicable to large-scale commercial 130 networks, multicast networks need to have the same capabilities which 131 are currently supported by unicast networks. Such issues important 132 to commercial, large-scale implementations of multicasting are listed. 133 Next, a few possible existing architectures used for multicasting 134 with access control based on current standards are presented. 135 Specifically 1) IGMP/ MLD, 2) IGMP/MLD with L2 Authentication with 136 ACL 3) Unicast Control with IGMP/MLD and 4) IGMP/MLD with Multicast 137 Encryption will each be presented and described. Each architecture 138 is discussed with respect to the presented list of issues. 140 2. Definitions and Abbreviations 142 2.1 Definitions 144 For the purposes of this I-D the following definitions apply: 146 Accounting: actions for grasping each user's behavior, when she/he 147 starts/stops to receive a channel, which channel she/he receives, etc. 149 Authentication: action for identifying a user as a genuine one. 151 Authorization: action for giving permission to access the content or 152 network to a user. 154 Receiver: an end-host or end-client which receives content. A 155 receiver may be distinguishable by a network ID such as MAC address 156 or IP address. 158 User: a human with a user account. A user may possibly use multiple 159 reception devices. Multiple users may use the same reception device. 161 Note: The definition of a receiver (device) and a user (human) should 162 not be confused. 164 2.2 Abbreviations 166 For the purposes of this draft the following abbreviations apply: 168 ACL: Access Control List 170 CDS: Content Delivery Services 172 CSP: Content Service Provider 174 DRM: Data Rights Management 176 KEI: Key Exchange Identifier 177 NSP: Network Service Provider 179 QoS: Quality of Service 181 3. Common use models and network architecture implications 183 Issues such as user identification, access-control, tracking and 184 billing are common requirements for commercial content delivery 185 services (CDS) systems (and are important in many non-commercial CDS 186 systems as well.) These same requirements should be met for CDS 187 systems that employ multicasting. 189 In some cases a single entity may design and be responsible for a 190 system that covers the various common high-level requirements of a 191 commercial multicasting system such as 1) content serving, 2) the 192 infrastructure to multicast it, 3) network and content access control 193 mechanisms. In many cases however the content provision and network 194 provision roles are divided between separate entities. The I-D 195 draft-ietf-mboned-maccnt-req-00.txt[3] provides more detail of the 196 multiple versus single entity CDS network model. 198 As such it should not be assumed that the entity responsible for the 199 multicasting structure and the entity responsible for content serving 200 are the same. Indeed because the infrastructure for multicasting is 201 expensive and many content holders are not likely to be competent at 202 building and maintaining complicated infrastructures necessary for 203 multicasting, many content holders would prefer to purchase transport 204 and management services from a network service provider and thus 205 share the infrastructure costs with other content holders. 207 Similarly commercial network service providers do not generally 208 specialize in providing content and are unlikely to build and 209 maintain such a resource-intensive system without a certain level of 210 demand from content holders. 212 The business model of a single NSP providing multicasting services to 213 multiple CSP has certain implications: 215 - Need for user tracking and billing capabilities 217 - Need for network access control and/or content access control 218 satisfactory to the requirements of the CSP 220 - Methods for sharing information between the NSP and CSP to 221 make the above two possible 223 When the NSP and CSP are the same single entity the general 224 requirements are as follows. 226 - Need for user tracking and user-billing capabilities 228 - Need for access control and/or content protection at level 229 the entity deems appropriate 231 In the next section issues in multicasting related to commercial and 232 large-scale implementations are presented. Some presented issues are 233 not pertinent to cases where the NSP and CSP are the same entity. 235 4. Issues in multicasting related to commercial and large-scale 236 implementations 238 This section lists issues related to receiver access control in 239 current multicasting protocols which are especially important to 240 commercial, large-scale multicasting. More details concerning the 241 requirements related to these issues are provided in a separate I-D 242 draft-ietf-mboned-maccnt-req-00.txt[3]. References to that document 243 are provided as applicable below. 245 4.1 Access limits and resource issues 247 For commercial applications of multicasting, network and content 248 providers generally wish to be able to control the number of groups a 249 host can access at the same time. Also the network provider may wish 250 to limit the number of users accessing a multicast stream because of 251 bandwidth and processing issues between the receiver and the 252 multicast server. 254 With best-effort services (e.g. mail transfer, web surfing) strict 255 network resource allocation is not necessary, but for services with a 256 guaranteed QoS level (e.g. IP television, teleconferencing, VoIP) it 257 is necessary to allocate sufficient bandwidth and server resources to 258 each service. In order to guarantee certain QoS levels, it is 259 important for network providers to be able to protect their network 260 resources from being wasted (either maliciously or accidentally). 262 More detail on this topic is provided in I-D draft-ietf-mboned- 263 maccnt-00.txt, section "Issue of network resource protection." 265 4.2 Capability to distinguish between receivers (end hosts) 267 Currently the sender cannot distinguish which receivers (end hosts) 268 are actually receiving its information with current protocols 269 (IGMP/MLD.) The sender must rely on the information from the 270 multicasting routers. This can be complicated if the sender and 271 routers are maintained by different entities. There is currently no 272 standard way to share such information. 274 4.3 Capability to distinguish between users (as opposed to merely 275 hosts) 277 Many content providers would like to have detailed information on 278 which users (as opposed to merely hosts identified by physical 279 addresses, etc.) are consuming their content and information on 280 their usage behavior. More detail on this topic can be found in I-D 281 draft-ietf-mboned-maccnt-00.txt, section "User identification" 283 4.4 Channel "leave latency" 285 Commercial implementations of IP multicasting are likely to have 286 strict requirements in terms of user experience. Leave latency is 287 the time between when a user sends a signal that he/she wishes to 288 "leave" a group and when the network recognizes the "leave." 289 A separate I-D draft-ietf-mboned-maccnt-00.txt provides more detail 290 on this topic in the section "Channel 'leave latency'" 292 4.5 Surveillance of receiver by sender 294 4.5.1 Precise access log 296 It is necessary to precisely log information such as who (host/user) 297 is accessing what content at from what time (join action) until what 298 time (leave action). The result of the access-control decision (e.g. 299 results of authorization) would also be valuable information. 301 4.5.2 How to share user information 303 For commercial multicast applications where NSP and CSP are different 304 entities, there are a number of issues regarding how to share user 305 information between the NSP and CSP. For example, which entities 306 should be able to access which information relating to user-based 307 tracking? What is the user identifier that can be used between the 308 entities to distinguish among users, and which entities should be 309 able to recognize this identifier? Another important issue is how 310 the edge router should be able to access and then maintain user 311 information. The current situation of present architectures is that 312 only the NSP can get information about user activity, because user 313 activities are only observable from join/leave information logged on 314 edge devices which are under control of the NSP. 316 4.5.3 Trustworthy logs to monitor user activity 318 An important issue for commercial multicasting applications is how 319 the NSP can get trustworthy data on user activity which may be needed 320 for billing and statistics purposes. A standard way of logging user 321 activity and protecting the integrity of the logs does not exist. 322 Often network providers do not want to keep logs on untrusted user 323 terminals which can be tampered with. 325 4.6 Notification to users of the result of the join request 327 It is necessary to provide information to the user about the status 328 of his/her join request(granted/denied/other). 330 4.7 Triple Play 332 Ideally the NSP should be able to use the same infrastructure (such 333 as access control) to support commercial multicast services for the 334 so-called "triple play" services: voice (VoIP), video, and broadband 335 Internet access services. 337 4.8 DRM Protection 339 Digital Rights Management (DRM) is important but out of scope of this 340 I-D. 342 5. Description of existing architectures 344 In this section, existing architectures used for multicasting based 345 on current standards are defined. In section 6 these architectures 346 will be compared by the issues presented in section 4. 348 5.1 IGMP/MLD 350 Internet Group Management Protocol(IGMP) or Multicast Listener 351 Discovery (MLD) are protocols for layer 3 management of multicasting. 352 In IP multicast a receiver sends a request to a first-hop multicast 353 router to join a particular multicast group. The router is then 354 responsible for forwarding the appropriate data from the sender to 355 the receiver. 357 +----------+ +----------+ +----------+ +----------+ 358 | Sender | | Router | | L2SW | | Receiver | 359 | | | |<---------------1,JOIN--| | 360 | | | | | | | | 361 | |--------------------------------2,Data->| | 362 | | | | | | | | 363 | | | | | | | | 364 +----------+ +----------+ +----------+ +----------+ 366 For the sake of simplicity, the above diagram only shows the sequence 367 of requests for a single receiver. When multiple receivers are 368 requesting the same channel stream the data would be copied at the 369 multicasting router to serve the multiple streams. 371 5.2 IGMP/MLD plus L2/L3 Authentication with Access Control Policy 373 With a basic implementation of IGMP/MLD implementation, no 374 authorization is performed on the receiver. It is possible to 375 combine an IGMP/MLD implementation with Layer 2 or Layer 3 376 Authentication to provide an access-control mechanism at the first 377 point of attachment to the network, for example, using 802.X. 379 For example, a receiver may request to an L2 authentication server 380 for access to the network. The authentication controller then queries 381 the policy server with the receiver's credentials (such as IP or MAC 382 address), and if the receiver is determined to be an authorized user 383 of the network ("success"), the router downloads the ACL from the 384 policy sever. For example, users which are not on the ACL are 385 rejected. Then the Layer 2 Switch is directed to open a port for the 386 receiver to send a join request to the multicast router. The router 387 is then responsible for forwarding the appropriate data from the 388 sender to the receiver. 390 Note: ACL is one existing method to realize an access control policy. 391 Other methods exist. 393 +----------+ 394 | Policy | 395 | Server |\ 396 | | \ 397 +----------+ \ 4,ACL Download 398 | ^ \ 399 | | \ 400 V | V 401 +----------+ +----------+ +----------+ +----------+ 402 | L2 | | Router | | L2SW | | Receiver | 403 | | | | | | | | 404 | Auth. |<---------------------------- 1,Request-| | 405 | | | | | | | | 406 | |--------2,Success------------>X(3,Auth) | | 407 +----------+ | | | | | | 408 | | | | | | 409 +----------+ | | | | | | 410 | | | |<---------------5,Join---| | 411 | Sender | | | | | | | 412 | |------------>x------------------6,Data-->| | 413 | | | | | | | | | 414 +----------+ +--------|-+ +----------+ +----------+ 415 | 416 V 417 Key: 418 Auth: Authentication 420 5.3 Unicast Control with IGMP/MLD 422 The receiver first sends a unicast request to the sender which 423 resides in the CP's domain. This method is the same as that used in 424 unicast video-on �demand (VoD) systems. If authorization is 425 successful the sender sends the multicast address information via 426 unicast. With this multicast address the receiver does a IGMP\MLD 427 join as in described in 5.1. 428 +----------+ +----------+ +----------+ +----------+ 429 | Sender | | Router | | L2SW | | Receiver | 430 | | | | | | | | 431 | |<------------------------------1,Request-| | 432 | | | | | | | | 433 | |-------------------------------2,Success>| | 434 | | | | | | | | 435 | | | |<--------------3,Join----| | 436 | | | | | | | | 437 | |------------>x-----------------4,Data--->| | 438 | | | | | | | | | 439 | | | | | | | | | 440 +----------+ +--------|-+ +----------+ +----------+ 441 | 442 V 444 5.4 IGMP/MLD with Multicast Encryption 446 With a basic implementation of IGMP/MLD, no data protection is 447 performed on data sent to the receiver. No credential check is 448 performed on the receiver and any receiver can receive and use the 449 data. The IGMP/MLD with Multicast Encryption model assumes that the 450 sender is sending encrypted data and that for this data to be useful 451 to the receiver it must first request and receive a key from a group 452 controller and key server that is synchronized with the content 453 encryption occurring on the sender's data. 455 +----------+ +----------+ +----------+ +----------+ 456 | G.C. & | | Router | | L2SW | | Receiver | 457 | | | | | | | | 458 | Key S. |<------------------------------1,Request-| | 459 | | | | | | | | 460 | |-------------------------------2,Key---->| | 461 +----------+ | | | | | | 462 | | | | | | 463 +----------+ | | | | | | 464 | | | |<---------------3,Join---| | 465 | Sender | | | | | | | 466 | |------------>x------------------4,Data-->| | 467 | | | | | | | | | 468 +----------+ +--------|-+ +----------+ +----------+ 469 | 470 V 471 Key: 472 G.C. & Key S.= Group Controller and Key Server 474 6. Evaluation of architectures by issue 476 In this section the various issues raised in section four are 477 analyzed by each of the architectures introduced in section five. 479 6.1 Access limit capabilities, compared by architecture 481 Comparison of currently available architectures with respect to 482 limiting the access of multicast groups 484 - IGMP/MLD: It is not possible to limit data reception. 486 - L2/L3 authentication with access control policy: 487 With an ACL it is possible to limit access of multicast groups. 488 However it should be discussed as to how scalable this approach is 489 because configuring an ACL could be a labor-intensive task. 491 - IGMP/MLD with Unicast control: 492 It is possible for malicious users to reconfigure the receiver's 493 terminal to ignore the Unicast control. In this case, this 494 maliciously reconfigured terminal could send a join message even if 495 it is rejected by the network. In such a case, the ineligible 496 receiver would be able to receive the multicast. As such, this 497 method may not be strong enough to exclude ineligible access. 499 -Multicast Encryption: 500 It is possible for receivers to receive IP packets, even if they do 501 not possess the keys to decrypt them. A receiver may also be able to 502 store such received data until they discover a way to decrypt it. 503 Another disadvantage of this method is that network resources are 504 wasted if an ineligible receiver receives an encrypted content even 505 if they do not have a valid key. 507 6.2 Capability to distinguish between receivers, compared by 508 architecture 510 Comparison of currently possible protocol-based solutions. 512 -IGMP/MLD: 513 The sender has no direct line of contact with the receiver and 514 therefore cannot distinguish on a receiver-basis. (If the 515 interface is fixed to the receiver then the join-log can be used, but 516 this would mean portability is sacrificed. Moreover, this method is 517 not applicable to a case where the CSP and NSP are different 518 companies because CSP cannot access this join-log.) 520 -L2/L3 authentication with access control policy: 521 At the moment of L2/L3 authentication it is possible to recognize 522 receivers, but if there are multiple content service providers (CSP) 523 a single L2 Authorization Server cannot distinguish among the CSPs. 524 Therefore it would be necessary to gather the join logs. (If the 525 interface is fixed then the join-log can be used, but this would mean 526 portability is sacrificed. Moreover, this method is not applicable 527 to a case where the CSP and NSP are different companies because the 528 CSP cannot access this join-log.) 530 -IGMP/MLD with Unicast control : 531 It is possible to distinguish among receivers using Unicast control. 533 -Multicast Encryption: 534 If the Content Service Provider maintains the Key Server it is 535 possible to distinguish on the receiver-level. If the Network 536 Service Provider maintains the key server it is necessary to devise a 537 method for the NSP to notify the CSP. 539 6.3 Capability to distinguish between users, compared by architecture 541 Comparison of currently possible protocol-based solutions: 543 -IGMP/MLD: 544 Since there is no user-based information, it is not possible to 545 distinguish on the user-level. 547 -L2/L3 authentication with access control policy: 548 At the moment of L2/L3 Authentication it is possible to distinguish 549 on the user-level. 551 However it is difficult to combine user and group logs: it would be 552 necessary to match user IDs from L2-Auth logs and group IDs from the 553 Join logs to match users and groups. 555 -IGMP/MLD with unicast control : 556 Distinguishing by user is possible using unicast control. 558 -Multicast Encryption: 559 If the Content Provider manages the Key Server it is possible to 560 distinguish the user. 561 If the Network Service Provider manages the Key Server it is 562 necessary to notify the Content Provider. 564 6.4 Maintain guaranteed quality-level of data delivery (Voice, Video), 565 compared by architecture 567 Comparison of currently possible protocol-based solutions: 569 -IGMP/MLD: 570 It is not possible to reject a user attempting to access even if 571 there are not sufficient resources. 573 -L2/L3 authentication with access control policy: 574 The AAA server does not know whether there are sufficient resources 575 or not. This method still can provide a guaranteed QoS if every 576 channel has the same bandwidth and sufficient bandwidth are allocated 577 to each user beforehand. However, it is not possible to provide a 578 guaranteed QoS by comparing the available bandwidth and the necessary 579 bandwidth upon each user's request. 581 -IGMP/MLD with Unicast control : 582 When the CSP and NSP are separate entities it is not possible for the 583 CSP to make a proper authorization decision because only the NSP 584 grasps the network resource availability. 586 -Multicast Encryption: 588 It is not possible to reject a user attempting to access even if 589 there are not sufficient resources because the user can receive data 590 even without a valid key. 592 6.5 Fast leave for fast surfing capability, compared by architecture 594 Comparison of currently possible protocol-based solutions: 596 -IGMP/MLD: 597 It is possible to track on a per host level (based on host address) 598 therefore fast leave for fast surfing capability can be achieved. 600 -L2/L3 authentication with access control policy: 601 It is possible to track on a per host level (based on host address) 602 therefore fast leave for fast surfing capability can be achieved. 604 -IGMP/MLD with Unicast control : 605 Even if a quick leave is possible, changing to a new channel using 606 Unicast Control is slow (latency problem). 608 -Multicast Encryption: 609 Even if a quick leave is possible, delivery of the Key Exchange 610 Identifier(KEI) is slow. 612 6.6 Surveillance of receiver by sender, compared by architecture 614 Comparison of currently possible protocol-based solutions: 616 -IGMP/MLD: 617 With this protocol it is possible to log separately join and leave 618 actions, but it is difficult to match these join and leave actions 619 when analyzing the logs is heavy computation (scalability with 620 millions of users). 622 -L2/L3 authentication with access control policy: 623 In this solution, the leave action is not recorded unless some 624 additional mechanism such as IGMP/MLD snooping is used. In some 625 cases, users disconnect their terminals without sending leave 626 messages. In this case, it is not possible to determine when each 627 user's entry in the ACL should be deactivated. 629 -IGMP/MLD with Unicast control : 630 In this solution the leave action is not recorded. 632 -Multicast Encryption: 634 If logs are recorded for each renewal of keys, then it is possible to 635 track activity on a per-user basis. However if logs are only recorded 636 per content data download then such tracking is not possible. 638 It should be noted that authentication of the source of each 639 join/leave message is important. 641 6.7.Notification to users of the result of the join request compared by 642 architecture 644 Comparison of currently possible protocol-based solutions: 646 -IGMP/MLD: 647 After the join it is not possible to notify the user of the result of 648 the join request. 650 -L2/L3 authentication with access control policy: 651 After the join it is not possible to notify the user of the result of 652 the join request. 654 -IGMP/MLD with Unicast control : 655 After the join it is not possible to notify the user of the result of 656 the join request. 658 -Multicast Encryption: 659 After the join it is not possible to notify the user of the result of 660 the join request. 662 6.8 Comparison summary 664 In this section a variety of existing architectures used for 665 multicasting based on current standards were compared and evaluated. 666 None of these architectures can sufficiently meet all of the common 667 requirements for accounting, authentication and authorization in 668 commercial, large-scale IP multicasting. Therefore it is recommended 669 that framework(s) for sufficiently addressing such requirements be 670 explored. 672 7. IANA considerations 674 This I-D does not raise any IANA consideration issues. 676 8. Security considerations 678 This I-D does not raise any new security issues which are not already 679 existing in original protocols. Enhancement of multicast access 680 control capabilities may enhance security performance. 682 9. Conclusion 684 Issues such as user identification, access-control, tracking and 685 billing are common requirements for many content delivery services 686 (CDS) systems. When CDS systems employ multicasting with 687 architectures based on currently existing multicasting standards, it 688 is often necessary to deploy non-standardized solutions to meet these 689 common requirements. It is recommended that requirements be defined 690 to serve as a basis for creating standardized ways to address the 691 various issues discussed in this I-D which are limiting the 692 application of multicasting especially to commercial, large-scale CDS 693 services. Such requirements should take into consideration a range of 694 possible architectures based on multiple business or usage models. 696 Normative References 698 [1] B. Cain, et. al., "Internet Group Management Protocol, Version 3", 699 RFC3376, October 2002. 701 [2] R. Vida, et. al., "Multicast Listener Discovery Version 2 (MLDv2) 702 for IPv6", RFC3810, June 2004. 704 [3] Hayashi, et. al., "Accounting, Authentication and Authorization 705 Issues in Well Managed IP Multicasting Services", draft-ietf- 706 mboned-maccnt-req-00.txt, April 2005 708 Authors' Addresses 710 Tsunemasa Hayashi 711 NTT Network Innovation Laboratories 712 1-1 Hikari-no-oka, Yokosuka-shi, Kanagawa, 239-0847 Japan 713 Phone: +81 46 859 8790 714 Email: hayashi.tsunemasa@lab.ntt.co.jp 716 Haixiang He 717 Nortel Networks 718 600 Technology Park Drive 719 Billerica, MA 01801, USA 720 Phone: +1 978 288 7482 721 Email: haixiang@nortelnetworks.com 722 Hiroaki Satou 723 NTT Network Service Systems Laboratories 724 3-9-11 Midoricho, Musashino-shi, Tokyo, 180-8585 Japan 725 Phone : +81 422 59 4683 726 Email : satou.hiroaki@lab.ntt.co.jp 728 Hiroshi Ohta 729 NTT Network Service Systems Laboratories 730 3-9-11 Midoricho, Musashino-shi, Tokyo, 180-8585 Japan 731 Phone : +81 422 59 3617 732 Email: ohta.hiroshi@lab.ntt.co.jp 734 Susheela Vaidya 735 Cisco Systems, Inc. 736 170 W. Tasman Drive 737 San Jose, CA 95134 738 Phone: +1-408-525-1952 739 Email: svaidya@cisco.com 741 Comments 743 Comments are solicited and should be addressed to the mboned working 744 group's mailing list at mboned@lists.uoregon.edu_and/or the authors. 746 Full Copyright Statement 748 Copyright (C) The Internet Society (2005). 750 This document is subject to the rights, licenses and restrictions 751 contained in BCP 78, and except as set forth therein, the authors 752 retain all their rights. 754 This document and the information contained herein are provided on an 755 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 756 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 757 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 758 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 759 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 760 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 762 Intellectual Property 764 The IETF takes no position regarding the validity or scope of any 765 Intellectual Property Rights or other rights that might be claimed to 766 pertain to the implementation or use of the technology described in 767 this document or the extent to which any license under such rights 768 might or might not be available; nor does it represent that it has 769 made any independent effort to identify any such rights. Information 770 on the IETF's procedures with respect to rights in IETF Documents can 771 be found in BCP 78 and BCP 79. 773 Copies of IPR disclosures made to the IETF Secretariat and any 774 assurances of licenses to be made available, or the result of an 775 attempt made to obtain a general license or permission for the use of 776 such proprietary rights by implementers or users of this 777 specification can be obtained from the IETF on-line IPR repository at 778 http://www.ietf.org/ipr. 780 The IETF invites any interested party to bring to its attention any 781 copyrights, patents or patent applications, or other proprietary 782 rights that may cover technology that may be required to implement 783 this standard. Please address the information to the IETF at ietf 784 ipr@ietf.org. 786 Expiration 788 This Internet-Draft will expire on January 4, 2006. 790 Acknowledgement 792 Funding for the RFC Editor function is currently provided by the 793 Internet Society.