RMT T. Paila Internet-Draft Nokia Expires: August 10, 2003 February 9, 2003 FDALC - File Delivery for ALC draft-paila-rmt-fdalc-00.txt 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 10, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document defines unidirectional delivery of files. The specification builds on Asynchronous Layered Coding, the base protocol designed for massively scalable multicast distribution. Thus, this document specifies a technique called FDALC - a mechanism for signalling and mapping the properties of files to concepts of ALC in a way that allows receivers to assign those parameters for received objects. Paila Expires August 10, 2003 [Page 1] Internet-Draft FDALC February 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 4 3. File delivery . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1 File delivery session . . . . . . . . . . . . . . . . . . . . 5 3.2 File Delivery Table . . . . . . . . . . . . . . . . . . . . . 6 3.3 File Delivery Table Syntax . . . . . . . . . . . . . . . . . . 8 3.4 Multiplexing of files within a file delivery session . . . . . 9 4. Channels, layers and timing . . . . . . . . . . . . . . . . . 10 5. Describing file delivery sessions . . . . . . . . . . . . . . 11 5.1 File delivery session description with Session Description Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.2 File delivery session description with SDPng . . . . . . . . . 12 6. Receiver operation . . . . . . . . . . . . . . . . . . . . . . 13 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7.1 Example of delivery session description using SDP . . . . . . 15 7.2 Example of delivery session description using SDPng . . . . . 15 7.3 Example of File Delivery Table . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19 References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . 21 Paila Expires August 10, 2003 [Page 2] Internet-Draft FDALC February 2003 1. Introduction This document defines unidirectional delivery of files. The specification builds on Asynchronous Layered Coding (ALC), version 1 [3], the base protocol designed for massively scalable multicast distribution. ALC defines transport of arbitrary binary objects. For file delivery applications mere transport of objects is not enough, however. The end systems need to know what do the objects actually present. Thus, this document specifies a technique called FDALC - a mechanism for signalling and mapping the properties of files to concepts of ALC in a way that allows receivers to assign those parameters for received objects. Although this specification has been written in terms of multicast addressing, the techniques are similarly applicable for use with unicast addressing. This specification answers the following questions: * How does an ALC session represent a file delivery session? * How can the properties of delivered files be signaled in-band within the file delivery itself? * How to describe the existence, transport details and schedule of file delivery in the first place? * What is the internal structure of file delivery sessions wherein several files can be delivered within a single session? * How does file delivery receiver operate and handle the complete file delivery session? This specification is structured as follows. Chapter 3 begins by defining the file delivery session. Following that it introduces the File Delivery Table that forms the core part of this specification. Further, it discusses multiplexing issues of transport objects within a file delivery session. Chapter 4 defines the required parameters for describing file delivery sessions in general and specifically defines the way to use SDP [5] and SDPng [6] for the purpose. Chapter 5 explains an envisioned receiver operation for the receiver of the file delivery session. Chapter 6 gives examples of both describing the file delivery sessions as well as File Delivery Table. Last, chapter 7 outlines security considerations regarding file delivery. Paila Expires August 10, 2003 [Page 3] Internet-Draft FDALC February 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 [2]. Paila Expires August 10, 2003 [Page 4] Internet-Draft FDALC February 2003 3. File delivery Asynchronous Layered Coding is a protocol designed for delivery of arbitrary binary objects. It is especially suitable for massively scalable, unidirectional, multicast distribution. ALC provides the basic transport considered in this specification. In this specification the above-mentioned arbitrary binary objects are files. The core of this specification is to define how the properties of the files are carried in-band together with the files. As an example, a file referred by "www.ex.com/docs/file.txt". Using the example, the following properties describe the properties that need to be conveyed by the file delivery protocol. * Absolute location of the file, expressed as URL. In the above example: "www.ex.com/docs/file.txt" * File name (this can also be concluded from the URL). In the above example: "file.txt" * File type, expressed as MIME media type (this can be also be concluded from the extension of the file name). In the above example: "text/ascii" * File size, expressed as bytes. In the above example (imaginary): "5200" * Content encoding of the file, within transport. In the above example, the file could be encoded using ZLIB [7]. * Security properties of the file such as digital signatures, message digestives, etc. 3.1 File delivery session ALC is a protocol instantiation of Layered Coding Transport building block (LCT) [4]. Thus ALC inherits the session concept of LCT. In this document we will use concepts ALC/LCT session to collectively denote the interchangeable terms ALC session and LCT session. An ALC/LCT session consists of a set of logically grouped ALC/LCT channels associated with a single sender carrying packets with ALC/ LCT headers for one or more objects. An ALC/LCT channel is defined by the combination of a sender and an address associated with the channel by the sender. A receiver joins a channel to start receiving the data packets sent to the channel by the sender, and a receiver leaves a channel to stop receiving data packets from the channel. Paila Expires August 10, 2003 [Page 5] Internet-Draft FDALC February 2003 One of the fields carried in the ALC/LCT header is the Transmission Session ID (TSI). The TSI is scoped by the source IP address, and the (source IP address, TSI) pair uniquely identifies a session, i.e., the receiver uses this pair carried in each packet to uniquely identify from which session the packet was received in case the receiver is joined to multiple sessions. In case multiple objects are carried within a session another field within the ALC/LCT header, the Transport Object ID (TOI), identifies from which object within the session the data in the packet was generated. Note that each object is associated with a unique TOI within the scope of a session. When FDALC is used for file delivery the following rules apply: * The ALC/LCT session will be called file delivery session. * TOI field MUST be used. * TOI value '0' is reserved for File Delivery Table * Each file in a file delivery session MUST be associated with exactly one TOI (>0) in the scope of that session. 3.2 File Delivery Table The File Delivery Table (FDT) provides a mapping between a TOI value and the file properties of the object that the TOI is associated with. Each file delivery session MUST have a FDT that is local to the given session. The FDT SHOULD provide mapping for every TOI appearing within the session. The TOIs that are not resolved by the FDT are not considered a part of file delivery session. Thus, how to handle unmapped TOIs is left out of this specification. FDT is carried within the file delivery session and it uses the reserved TOI value '0'. The FDT MAY appear in any part of the file delivery session and even multiplexed with other objects. It is RECOMMENDED that FDT is delivered prior to the files that are descibed in the table. The following rules define the dynamics of the File Delivery Table: * Within a file delivery session, at least one FDT MUST be delivered. * A FDT MAY appear in any part of the file delivery session and even multiplexed with other objects (not FDTs, see the next rule). Paila Expires August 10, 2003 [Page 6] Internet-Draft FDALC February 2003 * Multiple FDTs can be carried in a file delivery session. In this case the FDTs MUST NOT be multiplexed packetwise; delivery of a previous FDT MUST end before the delivery of the next FDT starts. * It is RECOMMENDED that FDT is delivered prior to the files that are descibed in the table. * Each FDT MUST use the reserved TOI value of '0'. * Each FDT is complete and thus completely overwrites the information carried in the previous FDT.(Author's note: The wording is wrong. What I mean to say is that any given FDT will contain 'enough' information for the receiver. That is: it is not useful to describe past files in the session. Similarly, it allows dynamic addition of future files within the lifetime of the delivery session. Also, given a long term file delivery session the receivers may join in the middle of the session. Then it is the 'currently relevant' information they need.) * Each FDT has a version number 'FDT-Version:' that is contained in the version field of the FDT. For each file delivery session, version numbering starts from '0' and incremented by one for each new FDT. The maximum value for version field is '65536'. After reaching the maximum value for version, the numbering starts again from '0'. * Within a file delivery session, any TOI MUST NOT be defined more than once. An example: FDT version 0 defines TOI of value '3'. Now, subsequent FDTs can either keep TOI '3' unmodified on the table, or drop it. In the latter case the interpretation SHOULD be that the file has already been delivered. * A FDT is valid until its expiration time. FDT contains the expiry time stamp 'FDT-Expires:' for this purpose. The time is specified in NTC. When a subsequent FDT, with a higher version number, is received before the previous expiration time - this immediately expires the previous version. * A receiver may use an FDT after its expiration time if a new FDT has not been received and the session is still on-going. * A sender MUST use an expiry time in the future upon creation of an FDT. * FDT contains the size of the FDT itself 'FDT-Length:'(in bytes). Paila Expires August 10, 2003 [Page 7] Internet-Draft FDALC February 2003 3.3 File Delivery Table Syntax The file delivery table is an ASCII text file. FDT uses the following fields that are defined in HTTP/1.1 specification [10]: Content-Location, Content-Type, Content-MD5. Note that for FDALC only absolute URLs are allowed in Content-Location. The FDT conforms to the following syntax: FDT ::= FDT-header CRLF toi-descriptor CRLF *(toi-descriptor) FDT-header ::= "FDT-Version:" integer CRLF "FDT-Length:" integer CRLF "FDT-Expires:" integer CRLF toi-descriptor ::= toi-id ":" CRLF fields toi-id ::= integer fields ::= locator-field CRLF type-field CRLF length-field CRLF [encoding-field CRLF] [digest-field CRLF] locator-field ::= "Content-Location:" safe type-field ::= "Content-Type:" safe length-field ::= "Content-Length:" integer encoding-field ::= "Content-Encoding:" safe digest-field ::= "Content-MD5:" safe integer ::= POS-DIGIT *(DIGIT) alpha-numeric ::= ALPHA | DIGIT DIGIT ::= "0" | POS-DIGIT POS-DIGIT ::= "1"|"2"|"3"|"4"|"5"|"6"|"7"|"8"|"9" ALPHA ::= "a"|"b"|"c"|"d"|"e"|"f"|"g"|"h"|"i"|"j"|"k"| "l"|"m"|"n"|"o"|"p"|"q"|"r"|"s"|"t"|"u"|"v"| "w"|"x"|"y"|"z"|"A"|"B"|"C"|"D"|"E"|"F"|"G"| Paila Expires August 10, 2003 [Page 8] Internet-Draft FDALC February 2003 "H"|"I"|"J"|"K"|"L"|"M"|"N"|"O"|"P"|"Q"|"R"| "S"|"T"|"U"|"V"|"W"|"X"|"Y"|"Z" safe ::= alpha-numeric | "'" | "'" | "-" | "." | "/" | ":" | "?" | """ | "#" | "$" | "&" | "*" | ";" | "=" | "@" | "[" | "]" | "^" | "_" | "`" | "{" | "|" | "}" | "+" | "~" *(safe) 3.4 Multiplexing of files within a file delivery session The delivered files appear as objects (identified with TOIs) within the file delivery session. All the objects, including the FDT, MAY be multiplexed in any order and in parallel with each other. Note the exception with multiple FDTs: the packets belonging to two different versions of FDTs (carried in TOI '0') MUST NOT be multiplexed packetwise. Paila Expires August 10, 2003 [Page 9] Internet-Draft FDALC February 2003 4. Channels, layers and timing ALC/LCT uses a concept of channels. When using just one channel for an ALC session notion of 'prior' and 'after' are intuitively defined for the delivery of objects with respect to their delivery times. However, if multiple channels are used, it is not straightforward to state that an object was delivered 'prior' to the other. An object may begin to be delivered on one or more of those channels before the delivery of a second object begins. However, the use of multiple channels/layers may complete the delivery of the second object before the first. In this document, the relation of delivered objects in time may be critical to the subsequent action of the receivers. Thus the term 'prior' is used as a mandatory requirement that a first object MUST complete delivery prior, in time, to the second object. This is not a problem when objects are delivered sequentially using a single channel. Thus it is RECOMMENDED that only a single channel is used for the delivery of a single file delivery session. Paila Expires August 10, 2003 [Page 10] Internet-Draft FDALC February 2003 5. Describing file delivery sessions To start receiving a file delivery session, the receiver needs to know transport parameters associated with the session. Interpreting these parameters and starting the reception therefore represents the entry point from which on the receiver operation falls into the scope of this specification. The parameters of transport that the receiver needs to know are: * The source IP address * The number of channels in the session * The destination IP address and port number for each channel in the session * The Transport Session Identifier * The start time and optionally end time of the session * Some information that tells receiver, in the first place, that the session contains files that are of interest How the receiver acquires the above-mentioned parameters is out of scope of this document. The specification, in particular, does not mandate or exclude any mechanism. The description can be conveyed to the receiver via techniques such as Session Announcement Protocol [8], email, accessing URL, etc. However, the way to express the parameters using existing description techniques is important. Consequently, this specification defines an instantiation of file delivery session description using the following schemes: * Session Description Protocol (SDP) [5] * Session Description and Capability Negotiation (SDPng) [6] 5.1 File delivery session description with Session Description Protocol File delivery session is described using 'Media description' component of SDP as follows: * Media type is 'application' Paila Expires August 10, 2003 [Page 11] Internet-Draft FDALC February 2003 * Port number corresponds to the UDP port in which the file delivery session is to be transmitted. * Transport protocol is 'ALC/LCT'. * Media format is '0' * If not defined on session level, the destination IP address is contained in the 'c=' field of the media description. In addition, the file delivery session is described on session level as follows: * The source IP address is contained in the 'o=' field. * If there is only one channel in use in the file delivery session, the destination (or group) address can appear in two ways. It is either contained in the 'c=' field as a session level definition, or in the 'c=' field of the media description. * Session level timing field 't=' defines the start and end time of the file delivery session. For repetition, 'r=' field MAY be used. * A special attribute 'a=ALC-TSI:' is used on the session level. This attribute contains the ALC/LCT Transport Session Identifier associated with the file delivery session. * A special attribute 'a=ALC-CH:' is used on the session level to describe how many channels belong to this file delivery session. 5.2 File delivery session description with SDPng Paila Expires August 10, 2003 [Page 12] Internet-Draft FDALC February 2003 6. Receiver operation This chapter describes how the receiver of the file delivery is expected to work. Instead of a detailed state-by-state specification the following should be interpreted as a rough sequence of an envisioned file delivery receiver. It is RECOMMENDED that this sequence is used. 1. The receiver obtains the description of the file delivery session identified by the pair: (source IP address, Transport Session Identifier). The receiver also obtains the destination IP addresses and respective ports associated with the file delivery session. 2. The receiver joins or otherwise attaches to the media in order to receive packets associated with the file delivery session (source IP address, destination IP addresses, ports) 3. At about the start time of file delivery session, the receiver starts to receive. 4. The receiver receives ALC/LCT packets associated with (source IP address, destination IP address). The receiver checks that the packets match the declared Transport Session Identifier. If not, packets are silently discarded. 5. While receiving, the receiver keeps a space per Transport Object Identifier to construct the object. Multiple objects can be constructed in parallel. 6. If the last segment of an object was received and the associated TOI was '0' the receiver has received a complete File Delivery Table. The receiver checks the FDT version: If previous FDT does not exists or if the version number of the previous FDT is less than the received, the current FDT becomes the received one. Otherwise the received FDT is silently discarded. Note: if the receiver has received an FDT with the maximum value for version, the receiver restarts calculating versions from '0'. 7. If the last segment of an object was received and the associated TOI was other than '0' the receiver has received a file. The receiver looks up the current FDT and assigns file with the properties described in the FDT. The receiver also checks that received content length matches with the description in FDT and calculated MD5 matches with the description in the FDT. The actions receiver takes with imperfectly received files (missing data, mismatching digestive, etc.) is outside the scope of this specification. Paila Expires August 10, 2003 [Page 13] Internet-Draft FDALC February 2003 8. If the file delivery session end time has not been reached go back to 4. Otherwise end. Paila Expires August 10, 2003 [Page 14] Internet-Draft FDALC February 2003 7. Examples This section provides an example on how to describe the file delivery session using SDP and an example on File Delivery Table 7.1 Example of delivery session description using SDP The following example defines that there is a file delivery session available from 2873397496 NTC to 2873404696 NTC. The source address of file delivery session is 2201:056D::112E:144A:1E24 and the value for TSI is 3. The delivery uses two channels with IPv6 multicast addresses FF1E:03AD::7F2E:172A:1E24 and FF1E:03AD::7F2E:172A:1E30. The UDP ports are 12345 and 12346, respectively. v=0 o=user123 2890844526 2890842807 IN IP6 2201:056D::112E:144A:1E24 s=File delivery session example i=More information t=2873397496 2873404696 a=ALC-TSI:3 a=ALC-CH:2 m=application 12345 ALC/LCT 0 c=IN IP6 FF1E:03AD::7F2E:172A:1E24 m=application 12346 ALC/LCT 0 c=IN IP6 FF1E:03AD::7F2E:172A:1E30 7.2 Example of delivery session description using SDPng 7.3 Example of File Delivery Table --beginning of file-- FDT-Version:0 FDT-Length:200 FDT-Expires:2873404696 2: Content-Location:www.example.com/clips/movie1.mp4 Content-Type:video/MPEG4 Content-Length:380000 3: Content-Location:www.example.com/menu/movies.html Content-Type:text/html Content-Length:6100 Content-Encoding:gzip Paila Expires August 10, 2003 [Page 15] Internet-Draft FDALC February 2003 Content-MD5:Q2hlY2sgSW50ZWdyaXR5IQ== --end of file-- Paila Expires August 10, 2003 [Page 16] Internet-Draft FDALC February 2003 8. Security Considerations There is a risk of forged file delivery sessions. A malicious attacker may spoof file delivery (ALC/LCT) packets in order to initiate an attack. The attacker may have several objectives he or she wishes to achieve. The following are the most obvious risks, however not exhaustive. Denial of service attack can be caused by first declaring a small file size but actually sending unlimited amount of data. A receiver that does not compare the FDT information to the current progress of delivery is vulnerable to this attack. Also, this is why it is strongly RECOMMENDED that the FDT describing the TOI (and the respective file) arrives prior to the most part of the actual file. Therefore, a receiver MAY silently discard received files do not correlate to the most recently, prior to the file, received FDT. The denial of service attack can be also achieved by by malicious frequent insertion of large FDT. The attack would keep the receiver busy parsing the FDT and not doing anything else. The countermeasure is to protect the session with packet level authentication using IPSEC-AH [9]. Overwriting of system files. A malicious attacker may describe Content-Location field of TOI 'n' to point to a system file. Then, TOI 'n' would carry a trojan horse or some other type of virus. The file delivery receiver MUST NOT have a write access to the system file areas of the receiving system. Further, the receiver should discard entries of FDT pointing to system areas. Generally it is RECOMMENDED that the entire file delivery session is provided with authenticator protocol such as IPSEC-AH. The details of how to apply it and how to deliver the keys to receipients are not in the scope of this specification. Paila Expires August 10, 2003 [Page 17] Internet-Draft FDALC February 2003 9. Acknowledgements Paila Expires August 10, 2003 [Page 18] Internet-Draft FDALC February 2003 10. Contributors Juha-Pekka Luoma Nokia P.O. Box 100 (Visiokatu 1) Tampere FIN-33721 Finland EMail: juha-pekka.luoma@nokia.com Esa Jalonen Nokia P.O. Box 407 (Itamerenkatu 11-13) Helsinki FIN-00180 Finland EMail: esa.jalonen@nokia.com Paila Expires August 10, 2003 [Page 19] Internet-Draft FDALC February 2003 References [1] Bradner, S., "The Internet Standards Process -- Revision 3", RFC 2026, BCP 9, October 1996. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. [3] Luby, M., Gemmel, J., Vicisano, L., Rizzo, L. and J. Crowcroft, "Asynchronous Layered Coding (ALC) Protocol Instantiation", RFC 3450, December 2002. [4] Luby, M., Gemmel, J., Vicisano, L., Rizzo, L. and J. Crowcroft, "Layered Coding Transport (LCT) Building Block", RFC 3451, December 2002. [5] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, March 1998. [6] Kutscher, Ott and Bormann, "Session Description and Capability Negotiation", draft-ietf-mmusic-sdpng-05 (work in progress), July 2002. [7] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, May 1996. [8] Handley, M., Perkins, C. and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000. [9] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998. [10] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Author's Address Toni Paila Nokia Itamerenkatu 11-13 Helsinki FIN-00180 Finland EMail: toni.paila@nokia.com Paila Expires August 10, 2003 [Page 20] Internet-Draft FDALC February 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. Paila Expires August 10, 2003 [Page 21]