idnits 2.17.1 draft-ietf-mboned-rac-issues-02.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 788. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 799. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 806. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 812. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 (March 5, 2006) is 6599 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-10) exists of draft-ietf-mboned-maccnt-req-04 ** Downref: Normative reference to an Informational draft: draft-ietf-mboned-maccnt-req (ref. '3') Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 7 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: September 6, 2006 Hiroaki Satou, NTT 5 Hiroshi Ohta, NTT 6 Susheela Vaidya, Cisco Systems 8 March 5, 2006 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- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six 27 months and may be updated, replaced, or obsoleted by other documents 28 at any time. It is inappropriate to use Internet-Drafts as 29 reference material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on September 6, 2006. 39 Copyright Notice 41 Copyright (C) The Internet Society (2006) 43 Abstract 45 This memo evaluates the extent to which current multicasting 46 protocols can be used to address common requirements for commercial, 47 large-scale IP multicasting. Four existing possible multicasting 48 architectures (with or without some form of access or content 49 control) are presented. Then each architecture is analyzed with 50 respect to how it can or cannot satisfactorily address each issue. 51 This memo concludes that for many of these issues the possible 52 architectures based on present standards as they now exist require 53 non-standardized solutions to meet common use requirements. This 54 memo recommends for requirements to be defined that would set the 55 groundwork for framework(s) and solutions that sufficiently address 56 these limitations. 58 Copyright Notice...................................................1 59 1. Introduction....................................................3 60 2. Definitions and Abbreviations...................................4 61 2.1 Definitions....................................................4 62 2.2 Abbreviations..................................................5 63 3. Common use models and network architecture implications.........5 64 4. Issues in multicasting related to commercial and large-scale 65 implementations....................................................7 66 4.1 Access limits and resource issues..............................7 67 4.2 Capability to distinguish between receivers (end hosts)........7 68 4.3 Capability to distinguish between users (as opposed to merely 69 hosts).............................................................7 70 4.4 Minimizing Channel Join Latency and Leave Latency..............8 71 4.5 Surveillance of receiver by sender.............................8 72 4.5.1 Precise access logging.......................................8 73 4.5.2 How to share user information................................8 74 4.5.3 Trustworthy logs to monitor user activity....................8 75 4.6 Notification to users of the result of the join request........9 76 4.7 Sharing of Infrastructure for Support of Triple Play Services..9 77 4.8 DRM Protection.................................................9 78 5. Description of existing architectures...........................9 79 5.1 IGMP/MLD.......................................................9 80 5.2 IGMP/MLD plus L2/L3 Authentication with Access Control Policy.11 81 5.3 Unicast Control with IGMP/MLD.................................12 82 5.4 IGMP/MLD with Multicast Encryption............................13 83 6. Evaluation of architectures by issue...........................14 84 6.1 Access limit capabilities, compared by architecture...........14 85 6.2 Capability to distinguish between receivers, compared by 86 architecture......................................................15 87 6.3 Capability to distinguish between users, compared by 88 architecture......................................................16 89 6.4 Maintain guaranteed quality-level of data delivery (Voice, 90 Video), compared by architecture..................................17 91 6.5 Fast leave for fast surfing capability, compared by architecture 92 ..................................................................17 93 6.6 Surveillance of receiver by sender, compared by architecture..18 94 6.7.Notification to users of the result of the join request compared 95 by architecture...................................................19 96 6.8 Comparison summary............................................19 97 7. IANA considerations............................................20 98 8. Security considerations........................................20 99 9. Conclusion.....................................................20 100 Normative References..............................................20 101 Comments..........................................................22 102 Full Copyright Statement..........................................23 103 Intellectual Property.............................................23 104 Expiration........................................................24 105 Acknowledgement...................................................24 107 1. Introduction 109 The intention of this memo is to initiate a discussion on the state 110 of current multicasting protocols deployed for commercial, large- 111 scale multicasting and their capabilities to provide receiver access 112 control. 114 Existing IP multicasting protocols (as presented in Section 5) were 115 designed to meet certain sets of requirements that do not 116 necessarily include architectural considerations intended to support 117 commercial services. This memo presents a number of issues network 118 providers may face when they attempt to apply current multicasting 119 standards to commercial services. The extent to which existing 120 multicast protocols can or cannot satisfactorily deal with these 121 issues is explored. A few network models based on a range of 122 different business models are presented as a basis for defining 123 requirements. 125 Multicasting can be useful to make the network more scalable when a 126 large volume of information needs to be distributed to a large 127 number of receivers. However, multicasting according to current 128 standards (e.g., IGMPv3[1] and MLDv2[2]) has drawbacks compared to 129 unicasting in terms of its commercial applicability because of the 130 insufficiency of access control and protection of network resources 131 against malicious use or accidents. In order to be applicable to 132 large-scale commercial networks, multicast networks need to have the 133 same capabilities which are currently supported by unicast networks. 134 Such issues which are important to commercial, large-scale 135 implementations of multicasting are listed. Next, a few possible 136 existing architectures used for multicasting with access control 137 based on current standards are presented. Specifically 1) IGMP/ MLD, 138 2) IGMP/MLD with L2/L3 Authentication with ACL 3) Unicast Control 139 with IGMP/MLD and 4) IGMP/MLD with Multicast Encryption will each be 140 presented and described. Each architecture is discussed with 141 respect to the presented list of issues. 143 2. Definitions and Abbreviations 145 2.1 Definitions 147 For the purposes of this memo the following definitions apply: 149 Accounting: actions for grasping each user's behavior, when she/he 150 starts/stops to receive a channel, which channel she/he receives, 151 etc. 153 Authentication: action for identifying a user as a genuine one. 155 Authorization: action for giving permission to access the content or 156 network to a user. 158 Receiver: an end-host or end-client which receives content. A 159 receiver may be distinguishable by a network ID such as MAC address 160 or IP address. 162 Triple Play: voice (VoIP), video, and broadband Internet access 163 services. 165 User: a human with a user account. A user may possibly use multiple 166 reception devices. Multiple users may use the same reception device. 168 Note: The definition of a receiver (device) and a user (human) 169 should not be confused. 171 2.2 Abbreviations 173 For the purposes of this draft the following abbreviations apply: 175 ACL: Access Control List 177 CDS: Content Delivery Services 179 CP: Content Provider 181 DRM: Data Rights Management 183 KEI: Key Exchange Identifier 185 NSP: Network Service Provider 187 QoS: Quality of Service 189 3. Common use models and network architecture implications 191 Issues such as user identification, access-control, tracking and 192 billing are common requirements for commercial content delivery 193 services (CDS) systems (and are important in many non-commercial CDS 194 systems as well.) These same requirements should be met for CDS 195 systems that employ multicasting. 197 In some cases a single entity may design and be responsible for a 198 system that covers the various common high-level requirements of a 199 commercial multicasting system such as 1) content serving, 2) the 200 infrastructure to multicast it, 3) network and content access 201 control mechanisms. In many cases however the content provision and 202 network provision roles are divided between separate entities. The 203 memo draft-ietf-mboned-maccnt-04.txt [3, referred to hereafter in 204 this memo as MACCNT-draft] provides more detail of the multiple 205 versus single entity CDS network model. 207 As such it should not be assumed that the entity responsible for the 208 multicasting structure and the entity responsible for content 209 serving are the same. Indeed because the infrastructure for 210 multicasting is expensive and many content holders are not likely to 211 be competent at building and maintaining complicated infrastructures 212 necessary for multicasting, many content holders would prefer to 213 purchase transport and management services from a network service 214 provider and thus share the infrastructure costs with other content 215 holders. 217 Similarly commercial network service providers do not generally 218 specialize in providing content and are unlikely to build and 219 maintain such a resource-intensive system without a certain level of 220 demand from content holders. 222 The business model of a single network service provider (NSP) 223 providing multicasting services to multiple content providers CP has 224 certain implications: 226 -Need for user tracking and billing capabilities 227 -Need for network access control and/or content access control 228 satisfactory to the requirements of the CP 229 -Methods for sharing information between the NSP and CP to make 230 the above two possible 232 When the NSP and CP are the same single entity the general 233 requirements are as follows. 235 -Need for user tracking and user-billing capabilities 236 -Need for access control and/or content protection at level the 237 entity deems appropriate 239 In the next section issues in multicasting related to commercial and 240 large-scale implementations are presented. Some presented issues 241 are not pertinent to cases where the NSP and CP are the same entity. 243 4. Issues in multicasting related to commercial and large-scale 244 implementations 246 This section lists issues related to receiver access control in 247 current multicasting protocols which are especially important to 248 commercial, large-scale multicasting. To avoid unnecessary 249 duplication with MACCNT-draft, detail for some of these issues is 250 provided through references in the Normative Reference section. 252 4.1 Access limits and resource issues 254 For commercial applications of multicasting, network and content 255 providers generally wish to be able to control the number of groups 256 a host can access at the same time. Also the network provider may 257 wish to limit the number of users accessing a multicast stream 258 because of bandwidth and processing issues between the receiver and 259 the multicast server. This section corresponds to MACCNT-draft[3], 260 section 4.5.14.2 "Issue of network resource protection", and 4.2.1 261 "Access control", but provides more detail. 263 With best-effort services (e.g. mail transfer, web surfing) strict 264 network resource allocation is not necessary, but for services with 265 a guaranteed QoS level (e.g. IP television, teleconferencing, VoIP) 266 it is necessary to allocate sufficient bandwidth and server 267 resources to each service. More detail on the topic of network 268 resource protection is provided in section "Issue of network 269 resource protection" of the MACCNT-draft[3]. 271 4.2 Capability to distinguish between receivers (end hosts) 273 For detail on the topic on the capability to distinguish between 274 receivers, refer to MACCNT-draft[3], 4.1 the second paragraph which 275 begins with "With current protocols (IGMP/MLD), the sender cannot 276 distinguish 278 4.3 Capability to distinguish between users (as opposed to merely 279 hosts) 280 Detail related to the topic of user identification can be found in 281 section "User identification" of the MACCNT-draft[3], the first 282 paragraph. 284 4.4 Minimizing Channel Join Latency and Leave Latency 286 More detail on the topic of channel leave latency is provided in 287 section "Channel Join Latency and Leave Latency" of the MACCNT- 288 draft[3]. 290 4.5 Surveillance of receiver by sender 292 4.5.1 Precise access logging 294 For detail on the topic please refer to MACCNT-draft[3], 4.6 295 "Accounting and billing", especially the second paragraph which 296 begins with "To assemble such..." 298 4.5.2 How to share user information 300 For commercial multicast applications where NSP and CP are different 301 entities, there are a number of issues regarding how to share user 302 information between the NSP and CP. For example, which entities 303 should be able to access which information relating to user-based 304 tracking? What is the user identifier that can be used between the 305 entities to distinguish among users, and which entities should be 306 able to recognize this identifier? Another important issue is how 307 the edge router should be able to access and then maintain user 308 information. The current situation of present architectures is that 309 only the NSP can get information about user activity, because user 310 activities are only observable from join/leave information logged on 311 edge devices which are under control of the NSP. This section 312 corresponds to MACCNT-draft[3], section 4.5.1 "How to share user 313 information", but provides more detail than in the MACCNT-draft. 315 4.5.3 Trustworthy logs to monitor user activity 316 An important issue for commercial multicasting applications is how 317 the NSP can get trustworthy data on user activity which may be 318 needed for billing and statistics purposes. A standard way of 319 logging user activity and protecting the integrity of the logs does 320 not exist. Often network providers do not want to keep logs on 321 untrusted user terminals that can be tampered with. 323 4.6 Notification to users of the result of the join request 325 Details for this issue are presented in MACCNT-draft[3], section 4.6 326 "Notification to users of the result of the join request." 328 4.7 Sharing of Infrastructure for Support of Triple Play Services 330 As stated in MACCNT-draft[3], section "Small impact on the existing 331 products": "Ideally the NSP should be able to use the same 332 infrastructure (such as access control) to support commercial 333 multicast services for the so-called 'triple play' services". 335 4.8 DRM Protection 337 Digital Rights Management (DRM) is important but out of scope of 338 this memo. 340 5. Description of existing architectures 342 In this section, existing architectures used for multicasting based 343 on current standards are defined. In section 6 these architectures 344 will be compared by the issues presented in section 4. 346 5.1 IGMP/MLD 348 Internet Group Management Protocol(IGMP) or Multicast Listener 349 Discovery (MLD) are protocols for layer 3 management of multicasting. 350 In IP multicast a receiver sends a request to a first-hop multicast 351 router to join a particular multicast group. The router is then 352 responsible for forwarding the appropriate data from the sender to 353 the receiver. 355 +----------+ +----------+ +----------+ +----------+ 356 | Sender | | Router | | L2SW | | Receiver | 357 | | | |<---------------1,JOIN--| | 358 | | | | | | | | 359 | |--------------------------------2,Data->| | 360 | | | | | | | | 361 | | | | | | | | 362 +----------+ +----------+ +----------+ +----------+ 364 For the sake of simplicity, the above diagram only shows the 365 sequence of requests for a single receiver. When multiple receivers 366 are requesting the same channel stream the data would be copied at 367 the multicasting router to serve the multiple streams. 369 5.2 IGMP/MLD plus L2/L3 Authentication with Access Control Policy 371 With a basic implementation of IGMP/MLD, no authorization is 372 performed on the receiver. It is possible to combine an IGMP/MLD 373 implementation with Layer 2 or Layer 3 Authentication to provide an 374 access-control mechanism at the first point of attachment to the 375 network, for example, using 802.1X. 377 For example, a receiver may request to an L2 authentication server 378 for access to the network. The authentication controller then 379 queries the policy server with the receiver's credentials (such as 380 IP or MAC address), and if the receiver is determined to be an 381 authorized user of the network ("success"), the router downloads the 382 ACL from the policy server. For example, users which are not on the 383 ACL are rejected. Then the Layer 2 Switch is directed to open a 384 port for the receiver to send a join request to the multicast router. 385 The router is then responsible for forwarding the appropriate data 386 from the sender to the receiver. 388 Note: ACL is one existing method to realize an access control policy. 389 Other methods exist. 391 +----------+ 392 | Policy | 393 | Server |\ 394 | | \ 395 +----------+ \ 4,ACL Download 396 | ^ \ 397 | | \ 398 V | V 399 +----------+ +----------+ +----------+ +----------+ 400 | L2 | | Router | | L2SW | | Receiver | 401 | | | | | | | | 402 | Auth. |<---------------------------- 1,Request-| | 403 | | | | | | | | 404 | |--------2,Success------------>X(3,Auth) | | 405 +----------+ | | | | | | 406 | | | | | | 407 +----------+ | | | | | | 408 | | | |<---------------5,Join---| | 409 | Sender | | | | | | | 410 | |------------>x------------------6,Data-->| | 411 | | | | | | | | | 412 +----------+ +--------|-+ +----------+ +----------+ 413 | 414 V 415 Key: 416 Auth: Authentication 418 5.3 Unicast Control with IGMP/MLD 420 The receiver first sends a unicast request to the sender which 421 resides in the CP's domain. This method is the same as that used in 422 unicast video-on-demand (VoD) systems. If authorization is 423 successful the sender sends the multicast address information via 424 unicast. With this multicast address the receiver does a IGMP\MLD 425 join as in described in 5.1. Generally this approach is relying on 426 either some sort of content encryption or "security through 427 obscurity" for content security. Also accounting becomes problematic 428 because user credentials may not be identified. 430 +----------+ +----------+ +----------+ +----------+ 431 | Sender | | Router | | L2SW | | Receiver | 432 | | | | | | | | 433 | |<------------------------------1,Request-| | 434 | | | | | | | | 435 | |-------------------------------2,Success>| | 436 | | | | | | | | 437 | | | |<--------------3,Join----| | 438 | | | | | | | | 439 | |------------>x-----------------4,Data--->| | 440 | | | | | | | | | 441 | | | | | | | | | 442 +----------+ +--------|-+ +----------+ +----------+ 443 | 444 V 446 5.4 IGMP/MLD with Multicast Encryption 448 With a basic implementation of IGMP/MLD, no data protection is 449 performed on data sent to the receiver. No credential check is 450 performed on the receiver and any receiver can receive and use the 451 data. The IGMP/MLD with Multicast Encryption model assumes that the 452 sender is sending encrypted data and that for this data to be useful 453 to the receiver it must first request and receive a key from a group 454 controller and key server that is synchronized with the content 455 encryption occurring on the sender's data. 457 +----------+ +----------+ +----------+ +----------+ 458 | G.C. & | | Router | | L2SW | | Receiver | 459 | | | | | | | | 460 | Key S. |<------------------------------1,Request-| | 461 | | | | | | | | 462 | |-------------------------------2,Key---->| | 463 +----------+ | | | | | | 464 | | | | | | 465 +----------+ | | | | | | 466 | | | |<---------------3,Join---| | 467 | Sender | | | | | | | 468 | |------------>x------------------4,Data-->| | 469 | | | | | | | | | 470 +----------+ +--------|-+ +----------+ +----------+ 471 | 472 V 473 Key: 474 G.C. & Key S.= Group Controller and Key Server 476 6. Evaluation of architectures by issue 478 In this section the various issues raised in section four are 479 analyzed by each of the architectures introduced in section five. 481 6.1 Access limit capabilities, compared by architecture 483 Comparison of currently available architectures with respect to 484 limiting the access of multicast groups 486 - IGMP/MLD: It is not possible to limit data reception. 488 - L2/L3 authentication with access control policy: 489 With an ACL it is possible to limit access of multicast groups. 490 However it should be discussed as to how scalable this approach is 491 because configuring an ACL could be a labor-intensive task. 493 - IGMP/MLD with Unicast control 494 It is possible for malicious users to reconfigure the receiver's 495 terminal to ignore the Unicast control. In this case, this 496 maliciously reconfigured terminal could send a join message even if 497 it is rejected by the network. In such a case, the ineligible 498 receiver would be able to receive the multicast. As such, this 499 method may not be strong enough to exclude ineligible access. 501 -Multicast Encryption: 502 It is possible for receivers to receive IP packets, even if they do 503 not possess the keys to decrypt them. A receiver may also be able to 504 store such received data until they discover a way to decrypt it. 505 Another disadvantage of this method is that network resources are 506 wasted if an ineligible receiver receives an encrypted content even 507 if they do not have a valid key. 509 6.2 Capability to distinguish between receivers, compared by 510 architecture 512 Comparison of currently possible protocol-based solutions. 514 -IGMP/MLD: 515 The sender has no direct line of contact with the receiver and 516 therefore cannot distinguish on a receiver-basis. (If the edge- 517 router's user interface is statically assigned then the interface's 518 log can be used to track joins, but this would mean portability is 519 sacrificed. Moreover, this method is not applicable to a case where 520 the CP and NSP are different companies because the CP cannot access 521 this join-log. Sharing of the join-log could be done with a yet-to- 522 be defined standard mechanism/format. ) 524 -L2/L3 authentication with access control policy: 525 At the moment of L2/L3 authentication it is possible to recognize 526 receivers, but if there are multiple content providers (CP) a single 527 L2 Authorization Server cannot distinguish among the CPs. Therefore 528 it would be necessary to gather the join logs. (If the interface is 529 fixed then the join-log can be used, but this would mean portability 530 is sacrificed. Moreover, this method is not applicable to a case 531 where the CP and NSP are different companies because the CP cannot 532 access this join-log.) 534 -IGMP/MLD with Unicast control : 536 It is possible to distinguish among receivers using Unicast control. 537 This latency may not be a problem when users are switching between 538 channels of the same CP in cases where the CP grants viewing 539 privileges uniformly across all of its channels. However, other 540 policies are possible that may be on a channel-basis, time-basis, 541 etc. and in such cases channel changing has latency issues. 543 -Multicast Encryption: 544 If the CP maintains the Key Server it is possible to distinguish on 545 the receiver-level. If the Network Service Provider maintains the 546 key server it is necessary to devise a method for the NSP to notify 547 the CP. 549 6.3 Capability to distinguish between users, compared by architecture 551 Comparison of currently possible protocol-based solutions: 553 -IGMP/MLD: 554 Since there is no user-based information, it is not possible to 555 distinguish on the user-level. 557 -L2/L3 authentication with access control policy: 558 At the moment of L2/L3 Authentication it is possible to distinguish 559 on the user-level. 561 However it is difficult to combine user and group logs: it would be 562 necessary to match user IDs from L2-Auth logs and group IDs from the 563 Join logs to match users and groups. 565 -IGMP/MLD with unicast control : 566 Distinguishing by user is possible using unicast control. 568 -Multicast Encryption: 569 If the Content Provider manages the Key Server it is possible to 570 distinguish the user. 571 If the Network Service Provider manages the Key Server it is 572 necessary to notify the Content Provider. 574 6.4 Maintain guaranteed quality-level of data delivery (Voice, Video), 575 compared by architecture 577 Comparison of currently possible protocol-based solutions: 579 -IGMP/MLD: 580 It is not possible to reject a user attempting to access even if 581 there are not sufficient resources. 583 -L2/L3 authentication with access control policy: 584 The AAA server does not know whether there are sufficient resources 585 or not. This method still can provide a guaranteed QoS if every 586 channel has the same bandwidth and sufficient bandwidth are 587 allocated to each user beforehand. However, it is not possible to 588 provide a guaranteed QoS by comparing the available bandwidth and 589 the necessary bandwidth upon each user's request. 591 -IGMP/MLD with Unicast control: 592 When the CP and NSP are separate entities it is not possible for the 593 CP to make a proper authorization decision because only the NSP 594 grasps the network resource availability. 596 -Multicast Encryption: 597 Having only encryption provides no access control and therefore 598 provides no mechanism to reject a user attempt to access when 599 sufficient resources are not available (i.e. the user can receive 600 data even without holding a valid key.) 602 6.5 Fast leave for fast surfing capability, compared by architecture 604 Comparison of currently possible protocol-based solutions: 606 -IGMP/MLD: 607 It is possible to track on a per host level (based on host address) 608 therefore fast leave for fast surfing capability can be achieved. 610 -L2/L3 authentication with access control policy: 611 It is possible to track on a per host level (based on host address) 612 therefore fast leave for fast surfing capability can be achieved. 614 -IGMP/MLD with Unicast control : 615 Even if a quick leave is possible, changing to a new channel using 616 Unicast Control is slow (latency problem). This latency may not be 617 a problem when users are switching between channels of the same CP 618 in cases where the CP grants viewing privileges uniformly across all 619 of its channels. However, other policies are possible that may be 620 on a channel-basis, time-basis, etc. and in such cases channel 621 changing has latency issues. 623 -Multicast Encryption: 624 Even if a quick leave is possible, delivery of the Key Exchange 625 Identifier(KEI) is slow. 627 6.6 Surveillance of receiver by sender, compared by architecture 629 Comparison of currently possible protocol-based solutions: 631 -IGMP/MLD: 632 With this protocol it is possible to separately log join and leave 633 actions, but it is difficult to match these join and leave actions 634 because analyzing the logs requires heavy computation (related to 635 the scalability with millions of users). 637 -L2/L3 authentication with access control policy: 638 In this solution, the leave action is not recorded unless some 639 additional mechanism such as IGMP/MLD snooping is used. In some 640 cases, users disconnect their terminals without sending logout 641 messages. Also it is possible that the user is running multiple 642 services and thus they will not log out even if they are finished 643 watching video or other multicast content. In this case, it is not 644 possible to precisely determine for accounting purposes when each 645 user disconnected. Also, it may be a problem that unused bandwidth 646 is being needlessly reserved. 648 However MLD/IGMP reports/joins need to be refreshed periodically. 649 The ACL entry can be deactivated if the user no longer refreshes the 650 report/join, but this means that user can be charged with unwatched 651 programs (125 seconds default.) This lack of precise timing may be a 652 problem in certain cases such as for paid services. 654 -IGMP/MLD with Unicast control : 655 In this solution the leave action is not recorded. 657 -Multicast Encryption: 658 If logs are recorded for each renewal of keys, then it is possible 659 to track activity on a per-user basis. However if logs are only 660 recorded per content data download then such tracking is not 661 possible. 663 It should be noted that authentication of the source of each 664 join/leave message is important. 666 6.7.Notification to users of the result of the join request compared by 667 architecture 669 Comparison of currently possible protocol-based solutions: 671 -IGMP/MLD: 672 After the join it is not possible to notify the user of the result 673 of the join request. 675 -L2/L3 authentication with access control policy: 676 After the join it is not possible to notify the user of the result 677 of the join request. 679 -IGMP/MLD with Unicast control : 680 After the join it is not possible to notify the user of the result 681 of the join request. 683 -Multicast Encryption: 684 After the join it is not possible to notify the user of the result 685 of the join request. 687 6.8 Comparison summary 689 In this section a variety of existing architectures used for 690 multicasting based on current standards were compared and evaluated. 692 None of these architectures can sufficiently meet all of the common 693 requirements for accounting, authentication and authorization in 694 commercial, large-scale IP multicasting. Therefore it is 695 recommended that framework(s) for sufficiently addressing such 696 requirements be explored. 698 7. IANA considerations 700 This memo does not raise any IANA consideration issues. 702 8. Security considerations 704 This memo does not raise any new security issues which are not 705 already existing in original protocols. Enhancement of multicast 706 access control capabilities may enhance security performance. 708 9. Conclusion 710 Issues such as user identification, access-control, tracking and 711 billing are common requirements for many content delivery services 712 (CDS) systems. When CDS systems employ multicasting with 713 architectures based on currently existing multicasting standards, it 714 is often necessary to deploy non-standardized solutions to meet 715 these common requirements. It is recommended that requirements be 716 defined to set the groundwork for creating framework(s) and 717 solutions that address the various issues discussed in this memo 718 which are limiting the application of multicasting especially to 719 commercial, large-scale CDS services. Such requirements should take 720 into consideration a range of possible architectures based on 721 multiple business or usage models. 723 Normative References 725 [1] B. Cain, et. al., "Internet Group Management Protocol, Version 726 3", RFC3376, October 2002. 728 [2] R. Vida, et. al., "Multicast Listener Discovery Version 2 729 (MLDv2) for IPv6", RFC3810, June 2004. 731 [3] Hayashi, et. al., "Accounting, Authentication and Authorization 732 Issues in Well Managed IP Multicasting Services", draft-ietf- 733 mboned-maccnt-req-04.txt, February 2006 [Work in Progress]. 735 Authors' Addresses 737 Tsunemasa Hayashi 738 NTT Network Innovation Laboratories 739 1-1 Hikari-no-oka, Yokosuka-shi, Kanagawa, 239-0847 Japan 740 Phone: +81 46 859 8790 741 Email: hayashi.tsunemasa@lab.ntt.co.jp 743 Haixiang He 744 Nortel Networks 745 600 Technology Park Drive 746 Billerica, MA 01801, USA 747 Phone: +1 978 288 7482 748 Email: haixiang@nortelnetworks.com 750 Hiroaki Satou 751 NTT Network Service Systems Laboratories 752 3-9-11 Midoricho, Musashino-shi, Tokyo, 180-8585 Japan 753 Phone : +81 422 59 4683 754 Email : satou.hiroaki@lab.ntt.co.jp 756 Hiroshi Ohta 757 NTT Network Service Systems Laboratories 758 3-9-11 Midoricho, Musashino-shi, Tokyo, 180-8585 Japan 759 Phone : +81 422 59 3617 760 Email: ohta.hiroshi@lab.ntt.co.jp 762 Susheela Vaidya 763 Cisco Systems, Inc. 764 170 W. Tasman Drive 765 San Jose, CA 95134 766 Phone: +1-408-525-1952 767 Email: svaidya@cisco.com 769 Comments 771 Comments are solicited and should be addressed to the mboned working 772 group's mailing list at mboned@lists.uoregon.edu_and/or the authors. 774 Full Copyright Statement 776 Copyright (C) The Internet Society (2006). 778 This document is subject to the rights, licenses and restrictions 779 contained in BCP 78, and except as set forth therein, the authors 780 retain all their rights. 782 This document and the information contained herein are provided on 783 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 784 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 785 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 786 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 787 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 788 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 790 Intellectual Property 792 The IETF takes no position regarding the validity or scope of any 793 Intellectual Property Rights or other rights that might be claimed 794 to pertain to the implementation or use of the technology described 795 in this document or the extent to which any license under such 796 rights might or might not be available; nor does it represent that 797 it has made any independent effort to identify any such rights. 798 Information on the procedures with respect to rights in RFC 799 documents can be found in BCP 78 and BCP 79. 801 Copies of IPR disclosures made to the IETF Secretariat and any 802 assurances of licenses to be made available, or the result of an 803 attempt made to obtain a general license or permission for the use 804 of such proprietary rights by implementers or users of this 805 specification can be obtained from the IETF on-line IPR repository 806 at http://www.ietf.org/ipr. 808 The IETF invites any interested party to bring to its attention any 809 copyrights, patents or patent applications, or other proprietary 810 rights that may cover technology that may be required to implement 811 this standard. Please address the information to the IETF at ietf- 812 ipr@ietf.org. 814 Expiration 816 This Internet-Draft will expire on September 6, 2006. 818 Acknowledgement 820 Funding for the RFC Editor function is currently provided by the 821 Internet Society.