idnits 2.17.1 draft-ietf-mmusic-img-req-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (December 2, 2003) is 7451 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) ** Obsolete normative reference: RFC 2327 (ref. '1') (Obsoleted by RFC 4566) ** Downref: Normative reference to an Experimental RFC: RFC 2974 (ref. '2') Summary: 6 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force MMUSIC WG 3 Internet Draft Y. Nomura 4 Fujitsu Labs. 5 R. Walsh 6 J-P. Luoma 7 Nokia 8 J. Ott 9 Universitaet Bremen 10 H. Schulzrinne 11 Columbia University 12 draft-ietf-mmusic-img-req-01.txt 13 December 2, 2003 14 Expires: March 2004 16 Protocol Requirements for Internet Media Guides 18 STATUS OF THIS MEMO 20 This document is an Internet-Draft and is in full conformance with 21 all provisions of Section 10 of RFC2026. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress". 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 To view the list Internet-Draft Shadow Directories, see 37 http://www.ietf.org/shadow.html. 39 Abstract 41 This memo specifies requirements for a protocol for accessing and 42 updating Internet Media Guide (IMG) information for media-on-demand 43 and multicast applications. These requirements are designed to guide 44 development of an IMG protocol for efficient and scalable delivery. 46 Table of Contents 47 1 Introduction ........................................ 2 48 1.1 Background and Motivation ........................... 2 49 1.2 Scope of this Document .............................. 4 50 2 Terminology ......................................... 4 51 3 Problem Statement ................................... 5 52 4 Requirements ........................................ 6 53 4.1 General Requirements ................................ 6 54 4.1.1 Independence of IMG Operations from IMG Metadata .... 6 55 4.1.2 Multiple IMG Senders ................................ 6 56 4.1.3 Modularity .......................................... 6 57 4.2 Delivery Properties ................................. 7 58 4.2.1 Scalability ......................................... 7 59 4.2.2 Support for Intermittent Connectivity ............... 7 60 4.2.3 Congestion Control .................................. 8 61 4.2.4 Sender and Receiver Driven Delivery ................. 8 62 4.3 Customized IMGs ..................................... 8 63 4.4 Reliability ......................................... 9 64 4.4.1 Managing consistency ................................ 9 65 4.4.2 Reliable Message Exchange ........................... 10 66 4.5 IMG Descriptions .................................... 10 67 5 Security Considerations ............................. 11 68 5.1 IMG Authentication and Integrity .................... 12 69 5.2 Privacy ............................................. 13 70 5.3 Access Control for IMGs ............................. 13 71 5.4 Denial-of-Service attacks ........................... 14 72 5.5 Replay Attacks ...................................... 14 73 6 Acknowledgements .................................... 14 74 7 Normative References ................................ 14 75 8 Informative References .............................. 15 76 9 Authors' Addresses .................................. 15 78 1 Introduction 80 1.1 Background and Motivation 82 For some ten years, multicast-based (multimedia) conferences 83 (including IETF WG sessions) as well as broadcasts of 84 lectures/seminars, concerts, and other events have been used in the 85 Internet, more precisely, on the MBONE. Schedules and descriptions 86 for such multimedia sessions as well as the transport addresses, 87 codecs, and their parameters have been described using SDP [1] as a 88 rudimentary (but as of then largely sufficient) means. Dissemination 89 of the descriptions has been performed using the Session Announcement 90 Protocol (SAP) [2] and tools such as SD [3] or SDR [4]; descriptions 91 have also been put up on web pages, sent by electronic mail, etc. 93 Recently, interest has grown to expand -- or better: to generalize -- 94 the applicability of these kinds of session descriptions. 95 Descriptions are becoming more elaborate in terms of included 96 metadata; more generic regarding the types of media sessions; and 97 possibly also support other transports than just IP (e.g. legacy TV 98 channel addresses). This peers well with the DVB Organization's 99 increased activities towards IP-based communications over satellite, 100 cable, and terrestrial radio networks, also considering IP as the 101 basis for TV broadcasts and further services. The program/content 102 descriptions are referred to as Internet Media Guides (IMGs) and can 103 be viewed as a generalization of Electronic Program Guides (EPGs) and 104 multimedia session descriptions. 106 An Internet Media Guide (IMG) is a structured collection of 107 multimedia session descriptions expressed using SDP, SDPng or some 108 similar session description format. It is used to describe a set of 109 multimedia sessions (e.g. television program schedules, content 110 delivery schedules etc.) but may also refer to other networked 111 resources including web pages. An IMG provides an envelope for 112 metadata formats and session descriptions defined elsewhere with the 113 aim of facilitating structuring, versioning, referencing, 114 distributing, and maintaining (caching, updating) such information. 116 The IMG metadata must be delivered to a potentially large audience, 117 who use it to join a subset of the sessions described, and who may 118 need to be notified of changes to the IMG. Hence, a framework for 119 distributing IMG metadata in various different ways is needed to 120 accommodate the needs of different audiences: For traditional 121 broadcast-style scenarios, multicast-based (push) distribution of IMG 122 metadata needs to be supported. Where no multicast is available, 123 unicast-based push is required, too. Furthermore, IMG metadata may 124 need to be retrieved interactively, similar to web pages (e.g. after 125 rebooting a system or when a user is browsing after network 126 connectivity has been re-established). Finally, IMG metadata may be 127 updated as time elapses because content described in the guide may be 128 changed: for example, the airtime of an event such as a concert or 129 sports event may change, possibly affecting the airtime of subsequent 130 media. This may be done by polling the IMG as well as asynchronous 131 change notifications. 133 Furthermore, we assume that any Internet host can be a sender of 134 content and thus an IMG. Some of the content sources and sinks may 135 only be connected to the Internet sporadically. Also, a single human 136 user may use many different devices to access metadata. Thus, we 137 envision that IMG metadata can be sent and received by, among others, 138 by cellular phones, PDA (Personal Digital Assistant), personal 139 computer, streaming video server, set-top box, video camera, and PVR 140 (Personal Video Recorder) and that they be carried across arbitrary 141 types of link layers, including bandwidth-constrained mobile 142 networks. 144 Finally, with many potential senders and sinks, different types of 145 networks, and presumably numerous service providers, IMG metadata may 146 need to be combined, split, filtered, augmented, modified, etc. on 147 their way from the sender(s) to the receiver(s) to provide the 148 ultimate user with a suitable selection of multimedia programs 149 according to her preferences, subscriptions, location, context (e.g. 150 devices, access networks), etc. 152 1.2 Scope of this Document 154 This document defines requirements that Internet Media Guide (IMG) 155 mechanisms must satisfy in order to deliver IMG to a potentially 156 large audience. Since the IMG can describe many kinds of multimedia 157 content, IMG methods are generally applicable to several scenarios. 159 In considering wide applicability, this document provides the problem 160 statement and existing mechanisms in this area. Then gives general 161 requirements that are independent of any transport layer mechanism 162 and application, such as delivery properties, reliability and IMG 163 descriptions. 165 This document reflects investigating work on delivery mechanisms for 166 IMGs and generalizing work on session announcement and initiation 167 protocols, especially in the field of the MMUSIC working group (SAP, 168 SIP [5], SDP). 170 2 Terminology 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 174 document are to be interpreted as described in RFC 2119 [6]. 176 Internet Media Guide (IMG): IMG is a generic term to describe 177 the formation, delivery and use of IMG metadata. The 178 definition of the IMG is intentionally left imprecise. 180 IMG Metadata: This is a set of metadata describing the features 181 of multimedia content used to enable selection of and 182 access to media sessions containing content. For example, 183 metadata may consist of the URI, title, airtime, bandwidth 184 needed, file size, text summary, genre, and access 185 restrictions. 187 IMG Delivery: The process of exchanging IMG metadata both in 188 terms of large scale and atomic data transfers. 190 IMG Sender: An IMG sender is a logical entity that sends IMGs to 191 one or more IMG receivers. 193 IMG Receiver: An IMG receiver is a logical entity that receives 194 IMGs from an IMG sender. 196 IMG Transceiver: An IMG transceiver combines an IMG receiver and 197 sender. It may modify original IMGs or merge several IMGs 198 from a different IMG sender. 200 IMG Operation: An atomic process for the IMG transport protocol 201 to deliver IMG metadata or control IMG sender(s) or IMG 202 receiver(s). 204 IMG Transport Protocol: A protocol that transports IMG metadata 205 from IMG sender to IMG receiver(s) 207 3 Problem Statement 209 The MMUSIC working group has long been investigating content, media 210 and service information delivery mechanisms and protocols, and has 211 itself produces Session Announcement Protocol (SAP), Session 212 Description Protocol (SDP), and the Session Initiation Protocol 213 (SIP). SDP is capable of describing multimedia sessions (i.e. 214 content in a wider sense) by means of limited descriptive information 215 intended for human perception plus transport, scheduling information, 216 and codecs and addresses for setting up media sessions. SIP and SAP 217 are protocols to distribute these session descriptions. 219 HTTP is a well known data retrieval protocol using bi-directional 220 transport and widely used to deliver content descriptions to many 221 hosts. 223 However, we perceive a lack of standard solution for scalable IMG 224 delivery mechanism in the number of receivers with consistency of IMG 225 metadata between an IMG sender and IMG receiver for both bi- 226 directional and unidirectional transport. With increased service 227 dynamics and complexity, there is an increased requirement for 228 updates to these content descriptions. 230 Whenever an HTTP client requires updated content descriptions, the 231 client has to reload those using the same URL. For mass media, the 232 large number of users polling a server causes scalability and 233 congestion concerns and so the technique is feasible only if the 234 period between reloading is long and the amount of content 235 descriptions or the number of users is small. A well-behaved 236 implementation limits the timeliness of receiver-side updates for 237 mass audiences. 239 The unicast equivalent of this is to maintain a unicast 240 connection/session between sender and receiver for the whole time a 241 receiver is interested in a service. This may be feasible in many 242 wire line systems for servers with only a few receivers, but both of 243 these become less attractive for both wireless links and large 244 numbers of sender-receiver connections, especially as both of these 245 share a resource (the radio bandwidth or the server resources) and 246 thus limit the number of receivers that can be served, without 247 additional infrastructure investment. 249 We also perceive a lack of standard solution for flexible content 250 descriptions to support a multitude of application-specific data 251 models with differing amount of detail and different target 252 audiences. 254 4 Requirements 256 4.1 General Requirements 258 4.1.1 Independence of IMG Operations from IMG Metadata 260 REQ GEN-1: Carrying different kinds of IMG metadata format in the IMG 261 message body MUST be allowed. 263 REQ GEN-2: Delivery mechanisms SHOULD support many different 264 applications specific metadata formats to keep the system 265 interoperable with existing applications. 267 This provides flexibility in selecting/designing delivery protocol 268 suited to various scenarios. 270 4.1.2 Multiple IMG Senders 272 REQ GEN-3: IMG receivers MUST be allowed to communicate with any 273 number of IMG senders simultaneously. 275 This might lead to receiving redundant IMG metadata describing the 276 same items, however it enables receiver access to more IMG metadata 277 than may be available from a single IMG sender. This also provides 278 flexibility for the delivery protocols and does not preclude a 279 mechanism to solve inconsistency among IMG metadata due to multiple 280 IMG senders. This document assumes a typical IMG environment will 281 involve many more receivers than senders and that senders are 282 continually connected for the duration of interest (rather than 283 intermittently connected). 285 4.1.3 Modularity 286 REQ GEN-4: The IMG delivery mechanisms MUST allow the combination of 287 several IMG Operations. 289 This is for the purpose of extending functionality (e.g. several or 290 one protocol(s) to provide all the needed operations). Applications 291 can select an appropriate operation set to fulfill their purpose. 293 4.2 Delivery Properties 295 This section describes general performance requirements based on the 296 assumption that the range of IMG usage shall be important. However, 297 it may be noted that requirements of delivery properties may vary 298 based on the usage scenario, and thus some limited use 299 implementations place less importance on some requirements. 301 For example, it is clear that a multicast transport may provide more 302 scalable delivery than a unicast transport, however scalability 303 requirements do not preclude the unicast transport mechanisms. In 304 this sense, scalability is always important for the protocols 305 irrespective of transport mechanisms. 307 4.2.1 Scalability 309 REQ DEL-1: The system MUST be scalable in that it does not fail to 310 deliver up-to-date information under huge numbers of transactions and 311 massive quantities of IMG metadata. 313 REQ DEL-2: IMGs SHOULD provide a method to prevent an IMG sender from 314 sending verbose IMG metadata that have been stored or deleted in IMG 315 receivers. Note, 'verbose' data is unneeded or unused detail or 316 repetitions. 318 REQ DEL-3: The protocol MUST be scalable to very large audience sizes 319 requiring IMG delivery. 321 4.2.2 Support for Intermittent Connectivity 323 REQ DEL-4: The system MUST enable IMG receivers with intermittent 324 access to network resources (connectivity) to receive and adequately 325 maintain sufficient IMG metadata. 327 This allows intermittent access to save power where there is no need 328 to keep communications links powered-up while they are sitting idle. 329 For instance, in this situation periodic bursts of notifies, or a 330 fast cycling update carousel, allows hosts to wake up for short 331 periods of time and still be kept up-to-date. This can be beneficial 332 for receivers with sporadic connects to the fixed Internet, but is 333 critical in the battery-powered wireless Internet. 335 4.2.3 Congestion Control 337 REQ DEL-5: Internet-friendly congestion control MUST be provided for 338 use on the public Internet. 340 For instance, notifications of updates (containing only minimal 341 change related data) can reduce congestion, especially for very large 342 groups, while allowing individual "congestion free" parts of the 343 Internet to do things "their way". Where some hosts are on 344 unidirectional links, and other have bi-directional links (or both), 345 this is sensible "diversity". 347 REQ DEL-6: An IMG entity SHOULD invalidate the IMG metadata item when 348 an IMG metadata item has lifetime information and its lifetime is 349 over. 351 This mechanism can reduce notifications of updates from the IMG 352 sender to receiver to invalidate the item. It may be beneficial for 353 congestion control. 355 4.2.4 Sender and Receiver Driven Delivery 357 REQ DEL-7: The system MUST be flexible in choosing sender-driven, 358 receiver-driven or both delivery schemes. 360 Sender-driven delivery achieves high scalability without interaction 361 between the IMG sender and receiver. This avoids keeping track of a 362 delivery state of every receiver. 364 In contrast, the receiver-driven delivery provides on-demand delivery 365 for IMG receivers. Since a sender's complete IMG metadata may be a 366 very large amount of data, the IMG receiver needs to be able to 367 access the guide when convenient (e.g., when sufficient network 368 bandwidth is available to the receiver). 370 4.3 Customized IMGs 372 REQ CUS-1: The system MUST allow delivery of customized IMG metadata. 374 The IMG receiver may require a subset of all the IMG metadata 375 available according to their preferences (type of content, media 376 description, appropriate age group, etc.) and configuration. 378 The IMG receiver might send its preferences in the IMG operations 379 which can specify user specific IMG metadata to be delivered. These 380 preferences could consist of filtering rules. When receiving these 381 messages, the IMG sender might respond appropriate messages carrying 382 a subset of IMG metadata which matches the receiver's preferences. 384 This mechanism can reduce the amount of IMG metadata delivered from 385 the sender to receiver, and consequently it can save the resource 386 consumption on the IMG entities and networks. It is typically useful 387 in unicast case and also beneficial in multicast case where IMG 388 sender distributes the same IMG metadata to interested IMG receivers 389 at the same time. 391 For multicast and unicast cases where the IMG sender does not provide 392 customized IMG metadata, the IMG receiver could receive all IMG 393 metadata transmitted (on its joined channels). However, it may select 394 and filter the IMG metadata to get customized IMG metadata by its 395 preferences, and thus drop unwanted metadata immediately upon 396 reception. 398 Customized metadata might be achieved by changing the IMG descriptors 399 sent and receivers and/or changing the delivery properties (channels 400 used). 402 Note, customization and scalability are only somewhat exclusive. 403 Systems providing receiver to sender request-based customization, 404 will be generally less scalable to massive receiver populations than 405 those without this return signaling technique. Thus, customization, 406 as with any feature which effects scalability, should be carefully 407 designed for the intended application, and it may not be possible 408 that a one-size-fits-all solution for customization would meet the 409 scalability requirements for all applications and deployment cases. 411 4.4 Reliability 413 4.4.1 Managing consistency 415 IMG metadata tends to change as time elapses, as new content is 416 added, the old IMG metadata stored in the IMG receiver becomes 417 unavailable and the parameters of the existing IMG metadata are 418 changed. 420 REQ REL-1: The system MUST manage IMG metadata consistency. 422 The IMG sender can either simply make updates available 423 (unsynchronized) or IMG sender and receiver can interact to keep 424 their copies of the IMG metadata synchronized. 426 In the unsynchronized model, the sender does not know whether a 427 particular receiver has an up-to-date copy of the IMG metadata. 429 In the synchronized model, updating cached copy of the IMG metadata 430 is necessary to control consistency when the IMG sender or receiver 431 could not communicate for a while. In this case, the IMG sender or 432 receiver may need to confirm its consistency by IMG operations. 434 REQ REL-2: Since IMG metadata can change at any time, IMG receivers 435 SHOULD be notified of such changes. 437 Depending on the size of the guide, the interested party may want to 438 defer retrieving the actual information. The change notification 439 should be addressed to a logical user (or user group), not a host, 440 since users may change devices. 442 Note that depending on the deployment environment and application 443 specifics, the level of acceptable inconsistency varies. Thus, this 444 document does not define inconsistency as specific time and state 445 differences between IMG metadata stored in an IMG sender and IMG 446 metadata stored in an IMG receiver. 448 In general, the consistency of metadata for a content and media is 449 more important immediately prior to and during the media's 450 session(s). Hosts which forward (or otherwise resend) metadata may be 451 less tolerant to inconsistencies as delivering out of date data is 452 both misleading and bandwidth inefficient. 454 By contrast, intermittent connectivity make immediate distribution of 455 changes infeasible and so managing data consistency should be focused 456 on the timely delivery of data. 458 4.4.2 Reliable Message Exchange 460 REQ REL-3: An IMG transport protocol MUST support reliable message 461 exchange. 463 The extent to which this could result in 100% error free delivery to 464 100% of receivers is a statistical characteristic of the protocols 465 used. Usage of reliable IMG delivery mechanisms is expected to depend 466 on the extent to which underlying networks provide reliability and, 467 conversely, introduce errors. Note, some deployments of IMG transport 468 protocols may not aim to provide perfect reception to all receivers 469 in all possible cases. 471 4.5 IMG Descriptions 473 REQ DES-1: IMG metadata MUST be interoperable over any IMG delivery 474 protocol, such that an application receiving the same metadata over 475 any one (or more) of several network connections and/or delivery 476 protocols will interpret the metadata in exactly the same way. (This 477 also relates to the 'Independence of IMG Operations from IMG 478 Metadata' requirement). 480 REQ DES-2: IMG delivery MUST enable the carriage of any format of 481 application-specific metadata. 483 Thus, the system will support the description of many kinds of 484 multimedia content, without the need for a single homogenous metadata 485 syntax for all uses (which would be infeasible anyway). This is 486 essential for environments using IMG systems to support many kinds of 487 multimedia content and to achieve wide applicability. 489 REQ DES-3: Whereas specific applications relying on IMGs will need to 490 select one or more specific application-specific metadata formats 491 (standard, syntax, etc.), the IMG system MUST be independent of this 492 (it may be aware, but it will operate in the same way for all). 494 Thus, a transfer envelope format, that is uniform across all 495 different application-specific IMG metadata formats, is needed. The 496 payload of this transfer envelope would be some application-specific 497 metadata. 499 REQ DES-4: IMG metadata MUST be structured such that it is possible 500 to deliver only part of a sender's (and the global) complete IMG 501 metadata knowledge. 503 REQ DES-5: A transfer envelope MUST be defined to include essential 504 parameters. 506 Examples of essential parameters are those that allow the metadata in 507 question to be uniquely identified and updated by new versions of the 508 same metadata. 510 REQ DES-6: It SHALL be possible to deduce the metadata format from 511 the transfer envelope. 513 REQ DES-7: IMG senders SHALL use the transfer envelope for each IMG 514 metadata transfer. 516 Thus, it will even be possible to describe relationships between 517 syntactically dissimilar application-specific formats within the same 518 body of IMG metadata knowledge. 520 REQ DES-8: IMG metadata SHOULD support to describe differences 521 between update version and old version of IMG metadata when IMG 522 delivery mechanism carries updated IMG metadata and those differences 523 are considerably little. (This also relates the delivery property 524 requirements for congestion control in Section 4.2.3). 526 5 Security Considerations 527 Internet Media Guides are used to convey information about multimedia 528 resources from one or more senders across one or intermediaries to 529 one or more receivers. IMG metadata may be pushed to the receivers or 530 interactively retrieved by them. IMGs provide metadata as well as 531 scheduling and rendezvous information about multimedia resources, 532 etc. and requests for IMG metadata may contain information about the 533 requesting users. 535 The information contained in IMG metadata as well as the operations 536 related to IMGs should be secured to avoid forging information, 537 misdirecting users, spoofing senders, etc. and to protect user 538 privacy. 540 The remainder of section addresses the security requirements for 541 IMGs. 543 5.1 IMG Authentication and Integrity 545 IMG metadata and its parts need to be protected against unauthorized 546 altering/adding/deletion on the way. Their originator needs to be 547 authenticated. 549 REQ AUT-1: It MUST be possible to authenticate the originator of a 550 set of IMG metadata. 552 REQ AUT-2: It MUST be possible to authenticate the originator of a 553 subpart of IMG metadata (e.g. a delta or a subset of the 554 information). 556 REQ AUT-3: It MUST be possible to validate the integrity of IMG 557 metadata. 559 REQ AUT-4: It MUST be possible to validate the integrity of a subpart 560 of IMG metadata (e.g. a delta or a subset of the information). 562 REQ AUT-5: It MUST be possible to separate or combine individually 563 authenticated pieces of IMG metadata (e.g. in an IMG transceiver) 564 without invalidating the authentication. 566 REQ AUT-6: It MUST be possible to validate the integrity of an 567 individually authenticated piece of IMG metadata even after this 568 piece had been separated from other pieces of IMG metadata and 569 combined with other pieces to form new IMG metadata. 571 REQ AUT-7: It MUST be possible to authenticate the originator of an 572 IMG operation. 574 REQ AUT-8: It MUST be possible to validate the integrity of any 575 contents of an IMG operation (e.g. the subscription or inquiry 576 information). 578 5.2 Privacy 580 Customized IMG metadata and IMG metadata delivered by notification to 581 individual users may reveal information about the habits and 582 preferences of a user and may thus deserve confidentiality 583 protection, even though the information itself is public. 585 REQ PRI-1: It MUST be possible to keep user requests to subscribe to 586 or retrieve certain (parts of) IMG metadata confidential. 588 REQ PRI-2: It MUST be possible to keep IMG metadata, pieces of IMG 589 metadata, or pointers to IMG metadata delivered to individual users 590 or groups of users confidential. 592 REQ PRI-3: It SHOULD be possible to ensure this confidentiality end- 593 to-end, that is, to prevent intermediaries (such as IMG transceivers) 594 from accessing the contained information. 596 5.3 Access Control for IMGs 598 Some IMG metadata may be freely available, while access to other may 599 be restricted to closed user groups (e.g. paying subscribers). Also, 600 different parts of IMG metadata may be protected at different levels: 601 e.g. metadata describing a media session may be freely accessible 602 while rendezvous information to actually access the media session may 603 require authorization. 605 REQ ACC-1: It MUST be possible to authorize user access to IMG 606 metadata. 608 REQ ACC-2: It MUST be possible to authorize access of users to pieces 609 of IMG metadata (delta information, subparts, pointers). 611 REQ ACC-3: It MUST be possible to require different authorization for 612 different parts of the same IMG metadata. 614 REQ ACC-4: It MUST be possible to access selected IMG metadata 615 anonymously. 617 REQ ACC-5: It MUST be possible for an IMG receiver to choose not to 618 receive (parts of) IMG metadata in order to avoid being identified by 619 the sender. 621 REQ ACC-6: It SHOULD be possible for IMG transceiver to impose 622 different authorization requirements. 624 REQ ACC-7: It MAY be possible for IMG senders to require certain 625 authorization that cannot be overridden by intermediaries. 627 5.4 Denial-of-Service attacks 629 Retrieving or distributing IMG metadata may require state in the 630 senders, transceivers, and/or receivers for the respective IMG 631 delivery sessions. Attackers may create large numbers of sessions 632 with any of the above IMG entities to disrupt regular operation. 634 REQ DOS-1: IMG operations SHOULD be authenticated. 636 REQ DOS-2: It SHOULD be possible to prevent DoS attacks that build up 637 session state in IMG entities to exhaust their resources. 639 REQ DOS-3: It SHOULD be possible to avoid DoS attacks that exhaust 640 resources of IMG entities by flooding them with IMG metadata. 642 5.5 Replay Attacks 644 IMG metadata disseminated by the sender or a transceiver may be 645 updated, deleted, or lose validity over time for some other reasons. 646 Replaying outdated IMG metadata needs to be prevented. 648 Furthermore, replay attacks may also apply to IMG operations (rather 649 than just their payload). Replaying operations needs also be 650 prevented. 652 REQ REP-1: IMG metadata MUST be protected against partial or full 653 replacement of newer ("current") versions by older ones. 655 REQ REP-2: Mechanisms MUST be provided to mitigate replay attacks on 656 the IMG operations. 658 6 Acknowledgements 660 The authors would like to thank Hitoshi Asaeda, Petri Koskelainen, 661 Toni Paila and Dirk Kutscher for their comments and ideas on this 662 work. 664 7 Normative References 666 [1] M. Handley and V. Jacobson, ``SDP: session description protocol,'' 667 RFC 2327, Internet Engineering Task Force, Apr. 1998. 669 [2] M. Handley, C. E. Perkins, and E. Whelan, ``Session announcement 670 protocol,'' RFC 2974, Internet Engineering Task Force, Oct. 2000. 672 [5] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J. 673 Peterson, R. Sparks, M. Handley, and E. Schooler, ``SIP: session 674 initiation protocol,'' RFC 3261, Internet Engineering Task Force, June 675 2002. 677 [6] S. Bradner, ``Key words for use in RFCs to indicate requirement 678 levels,'' RFC 2119, Internet Engineering Task Force, Mar. 1997. 680 8 Informative References 682 [3] Session Directory, ftp://ftp.ee.lbl.gov/conferencing/sd/ 684 [4] Session Directory Tool, http://www- 685 mice.cs.ucl.ac.uk/multimedia/software/sdr/ 687 9 Authors' Addresses 689 Yuji Nomura 690 Fujitsu Laboratories Ltd. 691 4-1-1 Kamikodanaka, Nakahara-ku, Kawasaki 211-8588 692 Japan 693 Email: nom@flab.fujitsu.co.jp 695 Rod Walsh 696 Nokia Research Center 697 P.O. Box 100, FIN-33721 Tampere 698 Finland 699 Email: rod.walsh@nokia.com 701 Juha-Pekka Luoma 702 Nokia Research Center 703 P.O. Box 100, FIN-33721 Tampere 704 Finland 705 Email: juha-pekka.luoma@nokia.com 707 Joerg Ott 708 Universitaet Bremen 709 MZH 5180 710 Bibliothekstr. 1 711 D-28359 Bremen 712 Germany 713 Email: jo@tzi.uni-bremen.de 715 Henning Schulzrinne 716 Dept. of Computer Science 717 Columbia University 718 1214 Amsterdam Avenue 719 New York, NY 10027 720 USA 721 Email: schulzrinne@cs.columbia.edu 723 Full Copyright Statement 725 Copyright (c) The Internet Society (2003). All Rights Reserved. 727 This document and translations of it may be copied and furnished to 728 others, and derivative works that comment on or otherwise explain it 729 or assist in its implementation may be prepared, copied, published 730 and distributed, in whole or in part, without restriction of any 731 kind, provided that the above copyright notice and this paragraph are 732 included on all such copies and derivative works. However, this 733 document itself may not be modified in any way, such as by removing 734 the copyright notice or references to the Internet Society or other 735 Internet organizations, except as needed for the purpose of 736 developing Internet standards in which case the procedures for 737 copyrights defined in the Internet Standards process must be 738 followed, or as required to translate it into languages other than 739 English. 741 The limited permissions granted above are perpetual and will not be 742 revoked by the Internet Society or its successors or assigns. 744 This document and the information contained herein is provided on an 745 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 746 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 747 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 748 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 749 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.