MMUSIC J.-P. Luoma Internet-Draft Nokia Expires: August 31, 2003 March 2, 2003 MUPPET: Internet Media Guide Unidirectional Point-to-Multipoint Transport draft-luoma-mmusic-img-muppet-01 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 31, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document defines MUPPET, a point-to-multipoint transport protocol for the delivery of Internet Media Guides over unidirectional access networks. This protocol is intended to be used with the Internet Media Guide framework, and in addition may be useful with other applications. Luoma Expires August 31, 2003 [Page 1] Internet-Draft MUPPET March 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1 Usage for Pushing IMG Metadata . . . . . . . . . . . . . . . 8 4.2 Usage for Pushing IMG Notifications . . . . . . . . . . . . 9 4.3 Combined Usage for Pushing IMG Metadata and Notifications . 9 4.4 Environmental Considerations . . . . . . . . . . . . . . . . 10 5. The MUPPET Protocol . . . . . . . . . . . . . . . . . . . . 11 5.1 Use of transport sessions . . . . . . . . . . . . . . . . . 11 5.2 Use of Transport Channels . . . . . . . . . . . . . . . . . 11 5.3 Protocol Framing . . . . . . . . . . . . . . . . . . . . . . 12 5.4 IMG Delivery Table . . . . . . . . . . . . . . . . . . . . . 15 5.5 Forward Error Correction . . . . . . . . . . . . . . . . . . 16 5.6 Payload segmentation . . . . . . . . . . . . . . . . . . . . 17 5.7 Use of Congestion Control . . . . . . . . . . . . . . . . . 17 5.8 Caching support . . . . . . . . . . . . . . . . . . . . . . 17 5.9 Authentication . . . . . . . . . . . . . . . . . . . . . . . 17 5.10 Encryption . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.11 Initial discovery of transport sessions . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . 19 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 Normative References . . . . . . . . . . . . . . . . . . . . 22 Author's Address . . . . . . . . . . . . . . . . . . . . . . 22 A. Example usage . . . . . . . . . . . . . . . . . . . . . . . 23 B. IDT Length Header Extension . . . . . . . . . . . . . . . . 24 Intellectual Property and Copyright Statements . . . . . . . 25 Luoma Expires August 31, 2003 [Page 2] Internet-Draft MUPPET March 2003 1. Introduction An Internet Media Guide (IMG) is a set of metadata describing available content such as streaming media and downloadable files. This document considers point-to-multipoint (p-t-m) transmission of IMG metadata over unidirectional access networks and defines a new transport protocol "MUPPET" for this purpose. An IMG metadata format suited for delivery with this protocol is defined in [7]. Luoma Expires August 31, 2003 [Page 3] Internet-Draft MUPPET March 2003 2. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Luoma Expires August 31, 2003 [Page 4] Internet-Draft MUPPET March 2003 3. Terminology Congestion Control Functionality of IMG senders allowing them to control their transmission rate in a way that is fair to the network. The lack of a feedback channel from receivers on unidirectional access networks limits the use of congestion control for downlink data and practically eliminates the need for congestion control on the uplink. Forward Error Correction (FEC) FEC data is redundant information generated from payload data and interleaved with it for transmission. The use of FEC allows receivers to reconstruct payload data segments lost or damaged due to transmission errors. IMG Fetch The client-controlled delivery of IMG metadata to an IMG receiver, based on a request-response model using acknowledgements if required. IMG Metadata Set An IMG metadata set is a collection of IMG metadata [7] comprising the full or partial IMG of an IMG sender. The MUPPET protocol provides transport service to IMG metadata sets. IMG Notify Informs IMG receivers about a change in the IMG metadata. It shall identify the parts of the IMG metadata that have changed without delivering the updated IMG metadata. A unidirectional notify provides only an indication, whereas notification on a bidirectional link may additionally require a response from the receivers. IMG Proxy An IMG proxy is an IMG transceiver that can filter from one or more IMG senders and output to one or more delivery channels. Logically a proxy fits in between IMG senders and receivers. A proxy may also cache IMG metadata and may provide its own bandwidth control or congestion control schemes on the output. Luoma Expires August 31, 2003 [Page 5] Internet-Draft MUPPET March 2003 IMG Push The sender-controlled delivery of IMG metadata to IMG receivers. This is inherently unidirectional. IMG Push-Notify The combination of an IMG push and IMG notify in the same message. IMG Receiver A logical entity that receives media guides from an IMG sender. IMG Sender A logical entity that delivers IMG metadata to one or more IMG receivers. A (multicast) sender shall provide bandwidth control or congestion control schemes on the output. A sender can additionally be a receiver - see IMG transceiver. IMG Subscribe A request for notifications of IMG metadata updates, from a receiver to a sender or proxy . IMG Transceiver A combination of an IMG receiver and sender. Transport channel Corresponds to the ALC/LCT definition of "channel" in RFC 3450 [4] and RFC 3451 [5]. Transport session Corresponds to the ALC/LCT definition of "session" in RFC 3450 [4] and RFC 3451 [5]. Luoma Expires August 31, 2003 [Page 6] Internet-Draft MUPPET March 2003 4. Overview The documents [2] and [3] describe the requirements and framework for Internet Media Guides (IMG), respectively, and identify several IMG transport services. One or more IMG transport protocol instantiations providing these conceptual IMG transport services need to be specified and the protocol implementations may vary between different network environments. Figure 1 shows the need for different IMG transport services depending on the use of Point-to-Point/Point-to-Multipoint delivery and the unidirectional/bidirectional property of the logical connection between the IMG sender and the IMG receivers. In the case of a unidirectional logical connection, it is expected that typically just the 'last-mile' access network link is unidirectional, while the rest of the access network consists of bidirectional links. +---------------+---------------+ |unidirectional | bidirectional | | (simplex) | (duplex) | +---------+---------------+---------------+ | | img_NOTIFY | img_SUBSCRIBE | | p-t-p | img_PUSH | img_NOTIFY | | unicast | | img_FETCH | | | | | +---------+---------------+---------------+ | | img_NOTIFY | img_SUBSCRIBE | | p-t-m | img_PUSH | img_NOTIFY | |multicast| | img_PUSH | | | | img_FETCH | +---------+---------------+---------------+ Figure 1: IMG Transport Matrix The IMG transport services shown in Figure 1 can be described as follows: o img_SUBSCRIBE is used by IMG receivers to request notifications of IMG metadata in [2]. o img_NOTIFY is used by the IMG sender to inform IMG receivers about a change in the IMG metadata. An implementation of this IMG transport service corresponds to the "Update notification" protocol component described in [2]. Luoma Expires August 31, 2003 [Page 7] Internet-Draft MUPPET March 2003 o img_PUSH provides server-controlled delivery of IMG metadata to IMG receivers. Either the full metadata or an update to the IMG metadata can be provided. The implementation of this IMG transport service can be shared with img_NOTIFY, or a separate implementation may be provided. o img_FETCH provides a receiver-controlled/receiver-initiated delivery of IMG metadata to IMG receivers. The delivery is typically either the full metadata or an update to the IMG metadata can be provided. An implementation of this IMG transport service corresponds to the "Program guide request" protocol component described in [2]. Because only a subset of the use cases provided by may be useful in some implementations, it is considered that a minimum of two IMG transport protocol specifications will be required and thus published: a point-to-multipoint instantiation; and, a point-to-point instantiation. Figure 2 below shows the use of different transport protocols to provide IMG transport services. In this figure, the name "MUPPET" refers to IMG p-t-m transport protocol being defined in this document, while "SIP" refers to the use of the Session Initiation Protocol with event notification mechanism. +--------------------------------------------+ IMG | | Content | METADATA | | | +------+--------+--------+-----------+-------+ Logical | | | | | | Transport | PUSH | NOTIFY | NOTIFY | SUBSCRIBE | FETCH | Service | | (p-t-m)| (p-t-p)| | | +------+--------+--------+-----------+-------+ Transport | | | | Protocol | MUPPET | SIP | HTTP | | | | | +---------------+--------------------+-------+ Figure 2: Relations between IMG transport services and transport protocols This document specifies a point-to-multipoint IMG transport protocol instantiation "MUPPET" that provides the IMG Transport Services img_NOTIFY and img_PUSH via unidirectional access networks. 4.1 Usage for Pushing IMG Metadata The IMG p-t-m unidirectional transport protocol provides the logical IMG push transport service for the delivery of an IMG sender's full Luoma Expires August 31, 2003 [Page 8] Internet-Draft MUPPET March 2003 IMG metadata or IMG metadata update. When used for sending updates, only the updated parts of IMG metadata are transmitted. To add reliability to transmissions over error-prone links the IMG sender SHOULD send IMG repetitively, by repeating a set of transmissions in carousel style or by sending individual transmissions multiple times. 4.2 Usage for Pushing IMG Notifications The IMG p-t-m unidirectional transport protocol provides the logical IMG notify transport service for the delivery of IMG update notifications. Although IMG delivery can be implemented without update notifications, it is RECOMMENDED to use them in the following cases: o No unidirectional metadata transfer for IMG updates: updated IMG metadata is never pushed to receivers, but can be obtained via a fetch operation. This case is only feasible if the receivers can at least intermittently access a bidirectional network connection. o Unidirectional metadata transfer for IMG updates only if sufficient demand: IMG updates are only pushed to clients if enough clients indicate (via out-of-band means) that they wish to receive the updates. o Unidirectional metadata transfer with bandwidth reduction: IMG updates are pushed to clients much less frequently than IMG update notifications. The notifications inform clients that part of their IMG data is no longer valid - they can either wait for an IMG update push via the unidirectional connection or fetch the IMG update via a bidirectional connection if available. 4.3 Combined Usage for Pushing IMG Metadata and Notifications An IMG sender MAY combine the following in the same IMG transfer, resulting in an IMG push-notify operation: o A notification of updates in parts of the IMG metadata o The actual metadata of other updated parts of the IMG As an example, only the changed IMG metadata considered most relevant to clients could be pushed to clients while the rest of the metadata Luoma Expires August 31, 2003 [Page 9] Internet-Draft MUPPET March 2003 would only be available via a fetch operation. 4.4 Environmental Considerations Figure 3 shows an IMG usage scenario where a single IMG sender is delivering IMG metadata to a number of IMG receivers. IP routing infrastructure is assumed and not shown. unidirectional ---------------> +----------+ downlink | IMG | ------------->| Receiver | / +----------+ +--------+ / . | IMG |----------- . | Sender | \ . +--------+ \ +----------+ ------------->| IMG | | Receiver | +----------+ Figure 3: Architecture of an IMG sender and IMG receivers Figure 4 shows an IMG usage scenario involving the optional use of an IMG proxy between IMG senders and IMG receivers. +----------+ unidirectional +----------+ | IMG | ---------------> | IMG | | Sender |---- downlink ---->| Receiver | +----------+ \ / +----------+ \ / . \ +-------+ / . . ---->| IMG |----- . . ---->| Proxy | \ . / +-------+ \ +----------+ / \ +----------+ | IMG | / ---->| IMG | | Sender |---- | Receiver | +----------+ +----------+ Figure 4: Architecture of IMG senders, IMG receivers and an IMG proxy An IMG proxy could be useful in the case that a service provider wishes to filter or mix IMG metadata originating from different sources, or needs to change the bandwidth allocation for IMG metadata between different network domains. Luoma Expires August 31, 2003 [Page 10] Internet-Draft MUPPET March 2003 5. The MUPPET Protocol The IMG Point-to-Multipoint Unidirectional Transport (MUPPET) protocol defined in this document uses multicast IP delivery to provide the following functionalities via unidirectional access networks: o Delivery of IMG metadata (img_PUSH) - transmission of the full metadata of an IMG or just the updated part of the IMG metadata. o Notification of a change in the IMG metadata (img_NOTIFY) - indication of a change in the IMG metadata. The MUPPET protocol essentially provides a multicast transport service for files containing IMG metadata. This transport service builds on the reliable multicast transport protocol Asynchronous Layered Coding (ALC) [4]. ALC provides a unidirectional transport service to binary objects, such as files. ALC is based on the is a Layered Coding Transport (LCT) reliable multicast protocol building block, and inherits the LCT concept of sessions comprising one or more layered channels. An ALC/LCT session consists of a set of logically grouped channels associated with a single sender carrying packets with ALC/LCT headers for one or more objects. MUPPET in turn is based on ALC and inherits the ALC/LCT concepts of sessions and channels, which in the scope of MUPPET are called transport sessions and transport channels (respectively). ALC as a generic multicast transport service leaves open implementation options and provides guidelines on extending the protocol. With its narrower scope, this specification will further specify the use of optional ALC features and extend the ALC protocol, as described in the following subsections. 5.1 Use of transport sessions The MUPPET protocol provides an IMG sender with unidirectional transport for its IMG metadata using one or more transport sessions. If more than one transport session is used, the sender's IMG metadata can be divided between transport sessions, for example based on the content category. The use of multiple transport sessions enables IMG receivers to selectively receive only parts of the IMG metadata. However, the use of more than one transport session for a single is outside the scope of the current version of this specification. 5.2 Use of Transport Channels Luoma Expires August 31, 2003 [Page 11] Internet-Draft MUPPET March 2003 Every transport session in MUPPET consists of one or more transport channels. Each of these channels carries MUPPET packets with the same value of the Transport Session Identifier (TSI) field, are sent from the same source port and IP address, and addressed to a different destination port and/or IP address. Any of the following transport channels MAY be included in a transport session. o Full channel - delivers the sender's full IMG metadata set using IMG push. o Update channel - delivers updates to the sender's full IMG metadata set using IMG push. o Notify channel - delivers notifications of updates to the sender's full IMG metadata set using IMG notify. IMG receivers with interactive network connection are able to join and leave transport channels at any moment, depending on the type of IMG metadata they need to receive and on the congestion status of the network. IMG receivers that only have unidirectional network connectivity are more restricted, but still have the option of filtering out unnecessary transport channels. Furthermore, a network element such as IMG proxy can reduce the number of transport channels forwarded to a unidirectional link, for example when congestion is detected at the feed of such a link. The IMG sender MUST indicate to receivers the addressing and use of different transport channels of a transport session . 5.3 Protocol Framing The MUPPET protocol re-uses the packet format of ALC/LCT defined in RFC 3450 [4] and RFC 3451 [5], with extensions defined in this document. MUPPET packets are carried over UDP, just as ALC/LCT packets. The MUPPET packet format is reproduced from [4] in Figure 5. Luoma Expires August 31, 2003 [Page 12] Internet-Draft MUPPET March 2003 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UDP header | | | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Default LCT header | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC Payload ID | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoding Symbol | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Overall MUPPET packet format The default LCT header in the figure above is of variable-length, as described in [5]. The use of the FEC payload ID is defined in [8]. The length and use of the different fields in the default LCT header portion is described in the following. MUPPET version number (V): 4 bits This field carries the version number of the MUPPET protocol, which also corresponds to the versions of ALC and LCT used. Currently, the value of this field is 1. Congestion control flag (C): 2 bits This field MUST have the value of 0, indicating that the 32-bit CCI field format is to be used. Reserved (r): 2 bits This field is reserved for future use. A sender MUST set these bits to zero and a receiver MUST ignore these bits. Transport Session Identifier flag (S): 1 bit This field MUST have the value of 1, indicating that the 32-bit TSI field format is to be used. Transport Object Identifier flag (O): 2 bits This field MUST have the value of 1, indicating that the 32-bit Luoma Expires August 31, 2003 [Page 13] Internet-Draft MUPPET March 2003 TOI field format is to be used. Half-word flag (H): 1 bit This field MUST have the value of 0. Sender Current Time present flag (T): 1 bit This field MUST have the value of 0, indicating that the Sender Current Time (SCT) field is not present in the LCT header. Expected Residual Time present flag (R): 1 bit This field MUST have the value of 0, indicating that the Expected Residual Time (ERT) field is not present in the LCT header. Close Session flag (A): 1 bit This field is normally set to 0. The sender MUST set A to 1 in all packets sent within a MUPPET session during the last few seconds before closing this session. Close Object flag (B): 1 bit This field is normally set to 0. The sender MUST set B to 1 in all packets for a transmission object during the last few seconds of transmitting that object. LCT header length (HDR_LEN): 8 bits As described in RFC 3450 [4]. Codepoint (CP): 8 bits The codepoint field is reserved for future use in MUPPET. A sender MUST set the field to zero and a receiver MUST ignore this field. Congestion Control Information (CCI): 32 bits The congestion control field is used to indicate the use of different transport channels to carry the full, update and notify channel of MUPPET (see Section 5.2). Transport Session Identifier (TSI): 32 bits Luoma Expires August 31, 2003 [Page 14] Internet-Draft MUPPET March 2003 The value of TSI field used for each MUPPET is obtained via out-of-band signaling, which is outside the scope of the current version this specification. Transport Object Identifier (TOI): 32 bits. The TOI values 0, 1 and 2 are reserved for the delivery of the IMG Delivery Table (Section 5.4) in MUPPET. This table in turn describes the use of other TOI values within each transport session. FEC Payload ID: X bits The size and interpretation of this field depends on the FEC scheme used, as described in RFC 3450 [4]. For the Compact No-Code FEC scheme that must be supported by all MUPPET implementations, the length of this field is 32 bits and its usage is defined in [9]. Encoding Symbol: Y bits This field is used to carry the payload of the MUPPET protocol. The receiver can determine the total length of this field by computing the total length of the received packet and subtracting off the length of the headers. For the TOI values of 0, 1 or 2 the payload is the IMG Delivery Table (Section 5.4); for other values of TOI, the payload is an IMG metadata set. 5.4 IMG Delivery Table The ALC protocol [4] provides unidirectional transport for arbitrary binary objects, called transport objects in this document. Each transport object is identified by the value of the Transport Object Identifier (TOI) field, which is unique within the scope of one transport session. MUPPET uses the transport service provided by the ALC protocol for the delivery of IMG metadata, sending each IMG metadata set as a separate transport object. The IMG Delivery Table (IDT) defined for MUPPET provides additional information on each transport object. Sender-side MUPPET implementations MUST insert the IDT in every transport session, and receiver-side MUPPET implementations MUST support parsing the IDT. A different IDT is transmitted for each type of MUPPET transport channel (Section 5.2) in a transport session. The following TOI Luoma Expires August 31, 2003 [Page 15] Internet-Draft MUPPET March 2003 values are reserved for IDTs according to the transport channel. o Full channel: 0 o Update channel: 1 o Notify channel: 2 The IMG Delivery Table (IDT) is defined as a set of mappings, each consisting of a TOI value and the properties of the transport object. The format of this table is TBD. The following HTTP-style attributes are described in the IDT for each transport object. o Content-Location: provides a URL that identifies the transport object across transport sessions o Content-Length: the length in bytes of the transport object o Content-Type (optional): the MIME type of the transport object - if absent, the IMG metadata format defined in [7] is assumed o Content-MD5 (optional): an MD5 checksum for the transport object o Content-Encoding (optional): the encoding used for the transport object (e.g. ZLIB compression) In addition, IMG Delivery Table contains the following fields describing the table itself. o IDT-Version: each IDT has a version number that is incremented by one for each new FDT o IDT-Expires (optional): the expected time of expiry for the current IDT version - instructional only o IDT-MD5 (optional): an MD5 checksum of the IDT, calculated without the IDT-MD5 field Note that the length of the IDT is not found in the IDT fields. However, this information is available in the IDT Length Header Extension (Appendix B) that IMG senders are REQUIRED to include in every MUPPET packet carrying IDT data. 5.5 Forward Error Correction MUPPET implementations are REQUIRED to support a Forward Error Correction scheme that is an instantiation of the reliable multicast FEC building block defined in [8], similarly to other ALC based Luoma Expires August 31, 2003 [Page 16] Internet-Draft MUPPET March 2003 protocols. The use of FEC with MUPPET is especially useful for receivers that only have unidirectional network connectivity via an error-prone link. It is not expected that FEC functionality is necessary to implement for MUPPET in all environments, for example on networks that provide sufficiently strong FEC on Layer 2. Therefore, only the Compact No-Code FEC scheme [9] MUST be supported in all MUPPET implementations. In addition, other FEC schemes compliant with [8] MAY also be supported. 5.6 Payload segmentation IP layer fragmentation of MUPPET packets is unwanted because of the loss-multiplier effect that reduces the efficiency of FEC schemes at higher protocol layers. Thus, the size of a MUPPET packet with protocol headers SHOULD be no larger than the Layer 2 MTU. 5.7 Use of Congestion Control The transport protocol defined in this document SHALL provide a mechanism for keeping the bandwidth consumption under given limits in a way compatible with RFC 2357 [6]. To support scenarios where MUPPET is deployed on a unidirectional access network with fully provisioned bandwidth allocation, implementations of this protocol SHOULD support a bandwidth control mechanism that does not require feedback from the receivers to the network. In accordance with RFC 2357, a bandwidth control mechanism that operates without receiver feedback MUST NOT be used on network links that are routed to the public Internet. 5.8 Caching support It may be necessary for an IMG proxy to look into the fields of the MUPPET payload [7] to enable better support of caching policies and congestion control. However, this may be restricted by the use of encryption (Section 5.10). 5.9 Authentication The MUPPET protocol SHALL support authenticated delivery of transport objects, allowing the integrity of the transported data to be verified (message authentication) and the sender to be identified (source authentication). The use of message authentication is RECOMMENDED, while the use of source authentication is OPTIONAL. The details of authentication are outside the scope of this specification. OPTIONALLY, network elements such as IMG proxies that need to modify Luoma Expires August 31, 2003 [Page 17] Internet-Draft MUPPET March 2003 the payloads of MUPPET messages MAY have sufficient trust to calculate and insert valid authentication information to the modified MUPPET packet. 5.10 Encryption This protocol SHALL support encrypted delivery of transport objects, only allowing the transported data to be decrypted by a given subset of the IMG receivers. The details of encryption are outside the scope of this specification. OPTIONALLY, network elements such as IMG proxies that need to modify the payloads of MUPPET messages MAY have sufficient trust to decrypt and re-encrypt MUPPET messages 5.11 Initial discovery of transport sessions The out-of-band signaling needed to initially discover the ports, IP addresses and TSI values used for transport sessions in MUPPET is TBD. Luoma Expires August 31, 2003 [Page 18] Internet-Draft MUPPET March 2003 6. Security Considerations The main security concerns with this protocol is how to protect IMG receiver from forged MUPPET messages. Such messages could be generated to prevent end-users from obtaining IMGs or to insert false information into IMGs. To enable receivers to detect message tampering, authentication information can be added to MUPPET transfers, allowing (at least some of) the IMG receivers to verify if IMG metadata originates from a particular IMG sender and if it has been tampered with. Another security concern is that IMG senders may not wish all of the IMG metadata transmitted with MUPPET to be accessible to all IMG receivers. This can be accomplished by encrypting some IMG metadata fields (partial encryption) or all of the IMG metadata (full encryption) transmitted as a single MUPPET transfer. Partial encryption of the MUPPET payload is best implemented at metadata-level (as described in [7]). Full encryption can be provided on any of the following layers: IMG metadata, MUPPET or lower protocol layers (such as IPsec or TLS). Encryption is currently not within the scope of MUPPET, but can be implemented as an extension to it or provided on other protocol layers. Luoma Expires August 31, 2003 [Page 19] Internet-Draft MUPPET March 2003 7. Contributors Rod Walsh Nokia Research Center P.O. Box 100 (Visiokatu 1) FIN-33721 Tampere Finland EMail: rod.walsh@nokia.com Toni Paila Nokia Ventures Organization P.O. Box 209 (Itamerenkatu 11-13) FIN-00181 Helsinki Finland EMail: toni.paila@nokia.com Luoma Expires August 31, 2003 [Page 20] Internet-Draft MUPPET March 2003 8. Acknowledgements The author would like to thank Yuji Nomura, Henning Schulzrinne, Rami Lehtonen, Jani Peltotalo and Sami Peltotalo for their feedback on this document. Luoma Expires August 31, 2003 [Page 21] Internet-Draft MUPPET March 2003 Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCD 14, March 1997. [2] Schulzrinne, H. and Y. Nomura, "Protocol Requirements for Internet Program Guides", draft-nomura-mmusic-img-requirements-00 (work in progress), February 2003. [3] Schulzrinne, H. and Y. Nomura, "A Framework for Internet Program Guides", draft-nomura-mmusic-img-framework-00 (work in progress), February 2003. [4] Luby, M., Gemmel, J., Vicisano, L., Rizzo, L. and J. Crowcroft, "Asynchronous Layered Coding (ALC) Protocol Instantiation", RFC 3450, December 2002. [5] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley, M. and J. Crowcroft, "Layered Coding Transport (LCT) Building Block", RFC 3451, December 2002. [6] Mankin, A., Romanow, A., Bradner, S. and V. Paxson, "IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols", RFC 2357, June 1998. [7] Luoma, J.-P., "Internet Media Guide Metadata Format", draft-luoma-mmusic-img-metadata-00 (work in progress), February 2003. [8] Luby, M., Vicisano, L., Gemmel, J., Rizzo, L., Handley, M. and J. Crowcroft, "Forward Error Correction (FEC) Building Block", RFC 3452, December 2002. [9] Vicisano, L. and M. Luby, "Compact Forward Error Correction (FEC) Schemes", draft-ietf-rmt-bb-fec-supp-inband-00 (work in progress), February 2003. Author's Address Juha-Pekka Luoma Nokia Research Center P.O. Box 100 (Visiokatu 1) Tampere FIN-33721 Finland EMail: juha-pekka.luoma@nokia.com Luoma Expires August 31, 2003 [Page 22] Internet-Draft MUPPET March 2003 Appendix A. Example usage Luoma Expires August 31, 2003 [Page 23] Internet-Draft MUPPET March 2003 Appendix B. IDT Length Header Extension The IDT table (Section 5.4) enables IMG receivers to discover the length of transport objects carrying IMG metadata within a transport session before starting to receive any of those transport objects. The length of the IDT itself is described in the IDT Length Header Extension located in the 'default LCT header' portion of the MUPPET header (Section 5.3). The IDT Length Header Extension belongs to the category of fixed-length Protocol Instance specific Header Extensions defined in [4] for ALC based protocols. The structure of this Header Extension is shown in Figure 6. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HET = 192 | IMG Delivery Table Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Format of IDT Length Header Extension The length and use of the subfields in the headers is described in the following. Header Extension Type (HET): 8 bits The type of the Header Extension. In the MUPPET protocol, the value of 192 identifies the IDT Length Header Extension. IMG Delivery Table Length: 24 bits The length in bytes of IMG Delivery Table, excluding MUPPET headers. Exactly one IDT Length Header Extension MUST be included in every MUPPET packet used for IDT transport. This Header Extension MUST NOT be used in any other MUPPET packets. Luoma Expires August 31, 2003 [Page 24] Internet-Draft MUPPET March 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Luoma Expires August 31, 2003 [Page 25] Internet-Draft MUPPET March 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Luoma Expires August 31, 2003 [Page 26]