idnits 2.17.1 draft-ietf-mmusic-img-req-00.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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (September 10, 2003) is 7527 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 (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force 3 Internet Draft Y. Nomura 4 Fujitsu Labs. 5 R. Walsh 6 Nokia 7 J. Ott 8 Universitaet Bremen 9 H. Schulzrinne 10 Columbia University 11 draft-ietf-mmusic-img-req-00.txt 12 September 10, 2003 13 Expires: March 2004 15 Protocol Requirements for Internet Media Guides 17 STATUS OF THIS MEMO 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress". 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 To view the list Internet-Draft Shadow Directories, see 36 http://www.ietf.org/shadow.html. 38 Abstract 40 This memo specifies requirements for a protocol for accessing and 41 updating Internet Media Guide (IMG) information for media-on-demand 42 and multicast applications. These requirements are designed to guide 43 development of an IMG protocol for efficient and scalable delivery. 45 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 Independence of IMG Operations from IMG Metadata .... 6 54 4.2 Multiple IMG Senders ................................ 6 55 4.3 Modularity .......................................... 6 56 4.4 Delivery Properties ................................. 6 57 4.4.1 Scalability ......................................... 7 58 4.4.2 Support for Intermittent Connectivity ............... 7 59 4.4.3 Congestion Control .................................. 7 60 4.5 Flexibility ......................................... 8 61 4.5.1 Customized IMGs ..................................... 8 62 4.5.2 Many Kinds of Multimedia Content .................... 8 63 4.5.3 Sender and Receiver Driven .......................... 8 64 4.6 Reliability ......................................... 9 65 4.6.1 Managing consistency ................................ 9 66 4.6.2 Reliable Message Exchange ........................... 10 67 4.7 IMG Descriptions .................................... 10 68 5 Security Considerations ............................. 10 69 5.1 IMG Authentication and Integrity .................... 11 70 5.2 Privacy ............................................. 11 71 5.3 Access Control for IMG .............................. 12 72 5.4 Denial-of-Service attacks ........................... 12 73 5.5 Replay Attacks ...................................... 13 74 6 Acknowledgements .................................... 13 75 7 Normative References ................................ 13 76 8 Informative References .............................. 13 77 9 Authors' Addresses .................................. 14 79 1 Introduction 81 1.1 Background and Motivation 83 For some ten years, multicast-based (multimedia) conferences 84 (including IETF WG sessions) as well as broadcasts of 85 lectures/seminars, concerts, and other events have been used in the 86 Internet, more precisely, on the MBONE. Schedules and descriptions 87 for such multimedia sessions as well as the transport addresses, 88 codecs, and their parameters have been described using SDP[1] as a 89 rudimentary (but as of then largely sufficient) means. Dissemination 90 of the descriptions has been performed using the Session Announcement 91 Protocol (SAP)[2] and tools such as SD[3] or SDR [4]; descriptions 92 have also been put up on web pages, sent by electronic mail, etc. 94 Recently, interest has grown to expand -- or better: to generalize -- 95 the applicability of these kinds of session descriptions. 96 Descriptions are becoming more elaborate in terms of included 97 metadata; more generic regarding the types of media sessions; and 98 possibly also support other transports than just IP (e.g. legacy TV 99 channel addresses). This peers well with the DVB Organization's 100 increased activities towards IP-based communications over satellite, 101 cable, and terrestrial radio networks, also considering IP as the 102 basis for TV broadcasts and further services. The program/content 103 descriptions are referred to as Internet Media Guides (IMGs) and can 104 be viewed as a generalization of Electronic Program Guides (EPGs) and 105 multimedia session descriptions. 107 An Internet Media Guide (IMG) is a structured collection of 108 multimedia session descriptions expressed using SDP, SDPng or some 109 similar session description format. It is used to describe a set of 110 multimedia sessions (e.g. television program schedules, content 111 delivery schedules etc.) but may also refer to other networked 112 resources including web pages. An IMG provides an envelope for 113 metadata formats and session descriptions defined elsewhere with the 114 aim of facilitating structuring, versioning, referencing, 115 distributing, and maintaining (caching, updating) such information. 117 The IMG must be delivered to a potentially large audience, who use it 118 to join a subset of the sessions described, and who may need to be 119 notified of changes to the IMG. Hence, a framework for distributing 120 IMGs in various different ways is needed to accommodate the needs of 121 different audiences: For traditional broadcast-style scenarios, 122 multicast-based (push) distribution of IMGs needs to be supported. 123 Where no multicast is available, unicast-based push is required, too. 124 Furthermore, IMGs may need to be retrieved interactively, similar to 125 web pages (e.g. after rebooting a system or when a user is browsing 126 after network connectivity has been re-established). Finally, IMG 127 data may be updated as time elapses because content described in the 128 guide may be changed: for example, the airtime of an event such as a 129 concert or sports event may change, possibly affecting the airtime of 130 subsequent media. This may be done by polling the IMG as well as 131 asynchronous change notifications. 133 Furthermore, we assume that any Internet host can be a source 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 IMGs can be sent and received by, among others, by 138 cellular phones, PDA (Personal Digital Assistant), personal computer, 139 streaming video server, set-top box, video camera, and PVR (Personal 140 Video Recorder) and that they be carried across arbitrary types of 141 link layers, including bandwidth-constrained mobile networks. 143 Finally, with many potential sources and sinks, different types of 144 networks, and presumably numerous service providers, IMGs may need to 145 be combined, split, filtered, augmented, modified, etc. on their way 146 from the sender(s) to the receiver(s) to provide the ultimate user 147 with a suitable selection of multimedia programs according to her 148 preferences, subscriptions, location, context (e.g. devices, access 149 networks), etc. 151 1.2 Scope of this Document 153 This document defines requirements that Internet Media Guide (IMG) 154 mechanisms must satisfy in order to deliver IMG to a potentially 155 large audience. Since the IMG can describe many kinds of multimedia 156 content, IMG methods are generally applicable to several scenarios. 158 In considering wide applicability, this document provides an analysis 159 of the problem space and existing mechanisms in this area. Then gives 160 general requirements that are independent of any transport layer 161 mechanism, existing protocol and application, such as performance, 162 flexibility and reliability. 164 This document reflects investigating work on delivery mechanisms for 165 IMGs and generalizing work on session announcement and initiation 166 protocols, especially in the field of the MMUSIC working group (SAP, 167 SIP[5], SDP). 169 2 Terminology 171 The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 172 SHOULD NOT, RECOMMENDED, MAY, and "OPTIONAL" in this document are to 173 be interpreted as described in RFC 2119 [6]. 175 Internet Media Guide (IMG): An IMG is a set of meta-data 176 describing the features of multimedia content. For example, 177 meta-data may consist of the URI, title, air time, 178 bandwidth needed, file size, text summary, genre, and 179 access restrictions. 181 IMG Delivery: The process of exchanging IMG metadata both in 182 terms of large scale and atomic data transfers. 184 IMG Sender: An IMG sender is a logical entity that sends IMGs to 185 one or more IMG receivers. 187 IMG Receiver: An IMG receiver is a logical entity that receives 188 IMGs from an IMG source. 190 IMG Transceiver: An IMG transceiver combines an IMG receiver and 191 sender. It may modify original IMGs or merge several IMGs 192 from a different IMG sender. 194 IMG Operations: An atomic process for the IMG protocol to 195 deliver IMG or control the IMG sender or IMG receiver. 197 3 Problem Statement 199 The MMUSIC working group has long been investigating content, media 200 and service information delivery mechanisms and protocols, and has 201 itself produces Session Announcement Protocol (SAP), Session 202 Description Protocol (SDP), and the Session Initiation Protocol 203 (SIP). SDP is capable of describing multimedia sessions (i.e. 204 content in a wider sence) by means of limited descriptive information 205 intended for human perception plus transport, scheduling information, 206 and codecs and addresses for setting up media sessions. SIP and SAP 207 are protocols to distribute these session descriptions. 209 Also in the IETF, HTTP is a well known information retrieval protocol 210 using bi-directional transport and widely used to deliver content 211 descriptions to many hosts. 213 However, we perceive a lack of standard solution for scalable IMG 214 delivery mechanism in the number of receivers with consistency of IMG 215 between an IMG sender and IMG receiver for both bi- and 216 unidirectional transport. With increased service dynamics and 217 complexity, there is an increased requirement for updates to these 218 content descriptions. 220 Whenever an HTTP client requires updated content descriptions, the 221 client has to reload those using the same URL. For mass media, the 222 large number of users polling a server causes scalability and 223 congestion concerns and so the technique is feasible only if the 224 period between reloading is long and the amount of content 225 descriptions or the number of users is small. A well-behaved 226 implementation limits the timeliness of receiver-side updates for 227 mass audiences. 229 The unicast equivalent of this is to maintain a unicast 230 connection/session between sender and receiver for the whole time a 231 receiver is interested in a service. This may be feasible in many 232 wireline systems for servers with only a few receivers, but both of 233 these become less attractive for both wireless links and large 234 numbers of sender-receiver connections, especially as both of these 235 share a resource (the radio bandwidth or the server resources) and 236 thus limit the number of receivers that can be served, without 237 additional infrastructure investment. 239 We also preceive a lack of standard solution for flexible content 240 descriptions to support a multitude of application-specific data 241 models with differing amount of detail and different target 242 audiences. 244 4 Requirements 246 4.1 Independence of IMG Operations from IMG Metadata 248 Carrying different kinds of IMG metadata format in the IMG message 249 body MUST be allowed. Delivery mechanisms SHOULD be agnostic to 250 applications specific metadata to keep the system interoperable with 251 existing applications. This provides flexibility in 252 selecting/designing delivery protocol suited to various scenarios. 254 4.2 Multiple IMG Senders 256 IMG receivers MUST be allowed to communicate with any number of IMG 257 senders simultaneously. This might lead to receiving redundant IMG 258 metadata describing the same items, however it enables receiver 259 access to more IMG metadata than may be available from a single IMG 260 sender. This also provides flexibility for the delivery protocols 261 and does not Preclude a mechanism to solve inconsistency among IMG 262 metadata due to multiple IMG senders. 264 4.3 Modularity 266 The IMG delivery mechanisms MUST allow the combination of several IMG 267 operations for the purpose of extending functionality (e.g. several 268 or one protocol(s) to provide all the needed operations). 269 Applications may select an appropriate operation set to fulfill their 270 purpose. 272 4.4 Delivery Properties 274 This section describes general performance requirements based on the 275 assumption that the range of IMG usage shall be important. However, 276 it may be noted that requirements of delivery properties may vary 277 based on the usage scenario, and thus some limited use 278 implementations place less importance on some requirements. 280 Example: It is clear that a multicast transport may provide more 281 scalable delivery than a unicast transport, however scalability 282 requirements do not preclude the unicast transport mechanisms. In 283 this sense, scalability is always important for the protocols 284 irrespective of transport mechanisms. 286 4.4.1 Scalability 288 The system MUST be scalable in that it does not fail to deliver up- 289 to-date information under huge numbers of transactions and massive 290 quantities of IMG Metadata. 292 An IMG system SHOULD provide a method to prevent an IMG sender from 293 sending verbose IMGs that have been stored or deleted in IMG 294 receivers. Note, 'verbose' data is unneeded or unused detail or 295 repetitions. 297 The protocol MUST be scalable to very large audience sizes requiring 298 IMG delivery. 300 4.4.2 Support for Intermittent Connectivity 302 The system MUST enable IMG receivers with intermittent access to 303 network resources (connectivity) to receive and adequately maintain 304 sufficient IMG metadata. 306 This allows intermittent access to save power where there is no need 307 to keep communications links powered-up while they are sitting idle. 308 For instance, in this situation periodic bursts of notifies, or a 309 fast cycling update carousel, allows hosts to wake up for short 310 periods of time and still be kept up-to-date. This may be beneficial 311 in the fixed-Internet, but is critical in the battery-powered 312 wireless Internet. 314 In addition, some of the IMG senders and receivers may only be 315 connected to the Internet sporadically. As an example, consider a 316 storage device requires the up-to-date video file from an IP- 317 reachable video camera but the camera is connected manually within a 318 limited period. When the camera is connected on the network and has a 319 new video object, the storage device must be notified of the 320 availability of the video file immediately. 322 4.4.3 Congestion Control 324 Internet-friendly congestion control MUST be provided. For instance, 325 notifications of updates (containing only minimal change related 326 data) can reduce congestion, especially for very large groups, while 327 allowing individual "congestion free" parts of the Internet to do 328 things "their way". Where some hosts are on unidirectional links, and 329 other have bi-directional links (or both), this is sensible 330 "diversity". 332 When an IMG item has lifetime information, the IMG entity SHOULD 333 invalidate the IMG item when its lifetime is over without any IMG 334 operations. This mechanism can reduce notifications of updates from 335 the IMG sender to receiver to invalidate the item. It may be 336 beneficial for congestion control. 338 4.5 Flexibility 340 4.5.1 Customized IMGs 342 The system MUST allow delivery of customized IMG metadata. The IMG 343 receiver may require a subset of the IMG according to their 344 preferences (type of content, media description, appropriate age 345 group, etc.) and configuration. 347 The IMG receiver may send its preferences in the IMG operations which 348 can specify user specific IMGs to be delivered. The preferences might 349 consist of filtering rules. When receiving these messages, the IMG 350 sender may respond appropriate messages carrying a subset of IMGs 351 which matches the receiver's preferences. 353 This mechanism can reduce the amount of IMGs delivered from the 354 sender to receiver, and consequently it can save the resource 355 consumption on the IMG entities and IMG networks. It is typically 356 useful in unicast case and also beneficial in multicast case where 357 IMG sender distributes the same IMGs to interested IMG receivers at 358 the same time. 360 In multicast case or unicast case where the IMG sender does not 361 provide customized IMGs, the IMG receiver may receive all IMG data 362 transmitted (on its joined channels). However, it may select and 363 filter the IMGs to get customized IMGs by its preferences, and thus 364 drop unwanted metadata immediately upon reception. 366 4.5.2 Many Kinds of Multimedia Content 368 The system MUST be able to deliver a variety of media descriptions, 369 which represents multimedia items available (e.g. by download, 370 streaming or multicast distribution.) This is essential for the 371 system to support many kinds of multimedia content and to achieve 372 wide applicability. 374 4.5.3 Sender and Receiver Driven 376 The system MUST be flexible in choosing sender-driven, receiver- 377 driven or both delivery schemes. Sender-driven delivery achieves high 378 scalability without interaction between the IMG sender and receiver. 379 This avoids keeping track of a delivery state of every receiver. 381 In contrast, the receiver-driven delivery provides on-demand delivery 382 for IMG receivers. Since an IMG may contain a large amount of data, 383 the IMG receiver needs to be able to access the guide when convenient 384 (e.g., when sufficient network bandwidth is available to the 385 receiver). 387 4.6 Reliability 389 4.6.1 Managing consistency 391 IMGs tend to change as time elapses, as new content is added, the old 392 IMG stored in the IMG receiver becomes unavailable and the parameters 393 of the existing IMG are changed. 395 The IMG sender can either simply make updates available 396 (unsynchronized) or IMG sender and receiver can interact to keep 397 their copies of the IMG synchronized. 399 In the unsynchronized model, the source does not know whether a 400 particular receiver has an up-to-date copy of the IMG. 402 In the synchronized model, updating cached copy of the IMG is 403 necessary to control consistency when the IMG sender or receiver 404 could not communicate for a while. In this case, the IMG sender or 405 receiver may need to confirm its consistency by IMG operations. 407 Since IMGs can change at any time, IMG receivers SHOULD be notified 408 of such changes. Depending on the size of the guide, the interested 409 party may want to defer retrieving the actual information. The 410 change notification should be addressed to a logical user (or user 411 group), not a host, since users may change devices. 413 Note that depending on the deployment environment and application 414 specifics, the level of acceptable inconsistency varies. Thus, this 415 document does not define inconsistency as specific time and state 416 differences between two IMG metadata stored in the IMG receiver and 417 IMG sender. 419 In general, the consistency of metadata is more important immediately 420 prior to and during the media session(s) duration (in time). Hosts 421 which forward (or otherwise resend) metadata may be less tolerant to 422 inconsistencies as delivering out of date data is both misleading and 423 is bandwidth inefficient. 425 By contrast, intermittent connectivity make immediate distribution of 426 changes infeasible and so managing data consistency should be focused 427 on the timely delivery of data. 429 4.6.2 Reliable Message Exchange 431 IMG transport MUST support reliable message exchange. The extent to 432 which this will result in 100 statistical characteristic of the 433 protocols used. Usage of reliable IMG delivery mechanisms is expected 434 to depend on the extent to which underlying networks provide 435 reliability and, conversely, introduce errors. 437 4.7 IMG Descriptions 439 IMG metadata MUST be interoperable over any IMG delivery protocol, 440 such that an application receiving the same metadata over any one (or 441 more) of several network connections and/or delivery protocols will 442 interpret the metadata in exactly the same way. (This also relates to 443 the 'Independence of IMG Operations from IMG Metadata' requirement). 445 IMG delivery MUST enable the carriage of any format of application- 446 specific metadata. Whereas specific applications relying on IMG shall 447 need to select one or more specific application-specific metadata 448 formats (standard, syntax, etc.), the IMG system shall be agnostic to 449 this (it may be aware, but it will operate in the same way for all). 451 Thus, a transfer envelope format, that is uniform across all 452 different application-specific IMG metadata formats, is needed. The 453 payload of this transfer envelope would be some application-specific 454 metadata. 456 IMG metadata MUST be structured such that it is possible to deliver 457 only part of a sender's (and the global) complete IMG knowledge MUST 458 be defined to include parameters, from the data model, that allow its 459 payload to be uniquely identified and updated by new versions of the 460 same payload. It SHALL be possible to deduce the payload format from 461 the transfer envelope. IMG senders SHALL use the transfer envelope 462 for each IMG Metadata transfer. Thus, it will even be possible to 463 describe relationships between syntactically dissimilar application- 464 specific formats within the same body of IMG metadata knowledge. 466 IMG metadata SHOULD support to describe differences between update 467 version and old version of IMG metadata when IMG delivery mechanism 468 carries updated IMG metadata and those differences are considerably 469 little. This also relates the delivery property requirements for 470 "Congestion Control". 472 5 Security Considerations 474 Internet Media Guides are used to convey information about multimedia 475 resources from one or more senders across one or intermediaries to 476 one or more receivers. IMGs may be pushed to the receivers or 477 interactively retrieved by them. IMGs contain metadata as well as 478 scheduling and rendezvous information about multimedia resources, 479 etc. and requests for IMGs may contain information about the 480 requesting users. 482 The information contained in IMGs as well as the operations related 483 to IMGs should be secured to avoid forging information, misdirecting 484 users, spoofing sneders, etc. and to protect user privacy. 486 This section addresses the security requirements for IMGs. 488 5.1 IMG Authentication and Integrity 490 IMGs and their constituents need to be protected against unauthorized 491 altering/adding/deletion on the way. Their originator needs to be 492 authenticated. 494 R: It MUST be possible to authenticate the originator of an IMG. 496 R: It MUST be possible to authenticate the originator of a subpart of 497 an IMG (e.g. a delta or a subset of the information). 499 R: It MUST be possible to validate the integrity of an IMG. 501 R: It MUST be possible to validate the integrity of a subpart of an 502 IMG (e.g. a delta or a subset of the information). 504 R: It SHOULD be possible to separate or combine individually 505 authenticated pieces of an IMG (e.g. in an IMG transceiver) without 506 invalidating the authentication. 508 R: It SHOULD be possible to validate the integrity of a piece of an 509 IMG even after this piece had been separated from other pieces of an 510 IMG and combined with other pieces to form a new IMG. 512 R: It MUST be possible to authenticate the originator of an IMG 513 related primitive. 515 R: It MUST be possible to validate the integrity of any contents of 516 an IMG related primitive (e.g. the subscription or inquiry 517 information). 519 5.2 Privacy 521 Customized IMGs and IMGs delivered by notification to individual 522 users may reveal information about the habits and preferences of a 523 user and may thus deserve confidentiality protection, even though the 524 information itself is public. 526 R: It MUST be possible to keep user requests to subscribe to or 527 retrieve certain (parts of) IMGs confidential. 529 R: It MUST be possible to keep IMGs, pieces of IMGs, or pointers to 530 IMGs delivered to individual users or groups of users confidential. 532 R: It SHOULD be possible to ensure this confidentiality end-to-end, 533 that is, to prevent intermediaries (such as IMG transceivers) from 534 accessing the contained information. 536 5.3 Access Control for IMG 538 Some IMGs may be freely available, while access to other may be 539 restricted to closed user groups (e.g. paying subscribers). Also, 540 different parts of an IMG may be protected at different levels: e.g. 541 metadata describing a media session may be freely accessible while 542 rendezvous information to actually access the media session may 543 require authorization. 545 R: It MUST be possible to authorize user access to IMGs. 547 R: It MUST be possible to authorize access of users to pieces of IMGs 548 (delta information, subparts, pointers). 550 R: It MUST be possible to require different authorization for 551 different parts of the same IMG. 553 R: It MUST be possible to access selected IMGs anonymously. 555 R: It MUST be possbile for an IMG receiver to choose not to receive 556 (parts of) an IMG in order to avoid authentication by the source. 558 R: It SHOULD be possible for IMG transceiver to impose different 559 authorization requirements. 561 R: It MAY be possible for IMG originators to require certain 562 authorization that cannot be overridden by intermediaries. 564 5.4 Denial-of-Service attacks 566 Retrieving or distributing IMGs may require state in the senders, 567 transceivers, and/or receivers for the respective IMG delivery 568 sessions. Attackers may create large numbers of sessions with any of 569 the above IMG entities to disrupt regular operation. 571 R: IMG operations SHOULD be authenticated. 573 R: It SHOULD be possible to prevent DoS attacks that build up session 574 state in IMG components to exhaust their resources. 576 R: It SHOULD be possible to avoid DoS attachs that exhaust resources 577 of IMG components by flooding them with IMG content. 579 5.5 Replay Attacks 581 IMGs dissiminated by the source or a transceiver may be updated, 582 deleted, or lose validity over time for some other reasons. 583 Replaying outdated IMGs needs to be prevented. 585 Furthermore, replay attacks may also apply to IMG operations (rather 586 than just their payload). Replaying operations needs also be 587 prevented. 589 R: IMGs MUST be protected against partial or full replacement of 590 newer ("current") versions by older ones. 592 R: Mechanisms MUST be provided to mitigate replay attacks on the IMG 593 operations. 595 6 Acknowledgements 597 The authors would like to thank Hitoshi Asaeda, Juka-Pekka Luoma , 598 Petri Koskelainen, Toni Paila and Dirk Kutscher for thier comments on 599 the draft. 601 7 Normative References 603 [1] M. Handley and V. Jacobson, ``SDP: session description protocol,'' 604 RFC 2327, Internet Engineering Task Force, Apr. 1998. 606 [2] M. Handley, C. E. Perkins, and E. Whelan, ``Session announcement 607 protocol,'' RFC 2974, Internet Engineering Task Force, Oct. 2000. 609 [5] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J. 610 Peterson, R. Sparks, M. Handley, and E. Schooler, ``SIP: session 611 initiation protocol,'' RFC 3261, Internet Engineering Task Force, June 612 2002. 614 [6] S. Bradner, ``Key words for use in RFCs to indicate requirement 615 levels,'' RFC 2119, Internet Engineering Task Force, Mar. 1997. 617 8 Informative References 619 [3] Session Directory, ftp://ftp.ee.lbl.gov/conferencing/sd/ 621 [4] Session Directory Tool, http://www- 622 mice.cs.ucl.ac.uk/multimedia/software/sdr/ 624 9 Authors' Addresses 626 Yuji Nomura 627 Fujitsu Laboratories Ltd. 628 4-1-1 Kamikodanaka, Nakahara-ku, Kawasaki 211-8588 629 Japan 630 Email: nom@flab.fujitsu.co.jp 632 Rod Walsh 633 Nokia Corporation 634 Nokia Research Center 635 P.O. Box 100, FIN-33721 Tampere 636 Finland 637 Email: rod,walsh@nokia.com 639 Joerg Ott 640 Universitaet Bremen 641 MZH 5180 642 Bibliothekstr. 1 643 D-28359 Bremen 644 Germany 645 tel:+49-421-201-7028 646 sip:jo@tzi.org 648 Henning Schulzrinne 649 Dept. of Computer Science 650 Columbia University 651 1214 Amsterdam Avenue 652 New York, NY 10027 653 USA 654 Email: schulzrinne@cs.columbia.edu 656 Full Copyright Statement 658 Copyright (c) The Internet Society (2003). All Rights Reserved. 660 This document and translations of it may be copied and furnished to 661 others, and derivative works that comment on or otherwise explain it 662 or assist in its implementation may be prepared, copied, published 663 and distributed, in whole or in part, without restriction of any 664 kind, provided that the above copyright notice and this paragraph are 665 included on all such copies and derivative works. However, this 666 document itself may not be modified in any way, such as by removing 667 the copyright notice or references to the Internet Society or other 668 Internet organizations, except as needed for the purpose of 669 developing Internet standards in which case the procedures for 670 copyrights defined in the Internet Standards process must be 671 followed, or as required to translate it into languages other than 672 English. 674 The limited permissions granted above are perpetual and will not be 675 revoked by the Internet Society or its successors or assigns. 677 This document and the information contained herein is provided on an 678 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 679 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 680 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 681 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 682 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.