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