idnits 2.17.1 draft-ietf-rmt-flute-revised-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1690. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1701. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1708. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1714. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 26, 2007) is 6028 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) == Missing Reference: '0' is mentioned on line 1352, but not defined == Missing Reference: '255' is mentioned on line 1352, but not defined == Unused Reference: '28' is defined on line 1545, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-rmt-pi-alc-revised-03 == Outdated reference: A later version (-11) exists of draft-ietf-rmt-bb-lct-revised-04 == Outdated reference: A later version (-07) exists of draft-ietf-rmt-fec-bb-revised-02 ** Obsolete normative reference: RFC 1305 (ref. '5') (Obsoleted by RFC 5905) ** Obsolete normative reference: RFC 2616 (ref. '6') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' ** Obsolete normative reference: RFC 3023 (ref. '9') (Obsoleted by RFC 7303) ** Obsolete normative reference: RFC 2279 (ref. '10') (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 2434 (ref. '11') (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 2327 (ref. '14') (Obsoleted by RFC 4566) -- Obsolete informational reference (is this intentional?): RFC 2633 (ref. '19') (Obsoleted by RFC 3851) -- Obsolete informational reference (is this intentional?): RFC 2048 (ref. '21') (Obsoleted by RFC 4288, RFC 4289) -- Obsolete informational reference (is this intentional?): RFC 3447 (ref. '24') (Obsoleted by RFC 8017) Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Reliable Multicast Transport (RMT) T. Paila 3 Internet-Draft R. Walsh 4 Expires: April 28, 2008 Nokia 5 M. Luby 6 Digital Fountain 7 R. Lehtonen 8 TeliaSonera 9 V. Roca 10 INRIA Rhone-Alpes 11 October 26, 2007 13 FLUTE - File Delivery over Unidirectional Transport 14 draft-ietf-rmt-flute-revised-05 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on April 28, 2008. 41 Copyright Notice 43 Copyright (C) The IETF Trust (2007). 45 Abstract 47 This document defines FLUTE, a protocol for the unidirectional 48 delivery of files over the Internet, which is particularly suited to 49 multicast networks. The specification builds on Asynchronous Layered 50 Coding, the base protocol designed for massively scalable multicast 51 distribution. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 1.1. Applicability Statement . . . . . . . . . . . . . . . . . 5 57 1.1.1. The Target Application Space . . . . . . . . . . . . . 5 58 1.1.2. The Target Scale . . . . . . . . . . . . . . . . . . . 5 59 1.1.3. Intended Environments . . . . . . . . . . . . . . . . 5 60 1.1.4. Weaknesses . . . . . . . . . . . . . . . . . . . . . . 6 61 2. Conventions used in this Document . . . . . . . . . . . . . . 6 62 3. File delivery . . . . . . . . . . . . . . . . . . . . . . . . 6 63 3.1. File delivery session . . . . . . . . . . . . . . . . . . 7 64 3.2. File Delivery Table . . . . . . . . . . . . . . . . . . . 9 65 3.3. Dynamics of FDT Instances within file delivery session . . 11 66 3.4. Structure of FDT Instance packets . . . . . . . . . . . . 12 67 3.4.1. Format of FDT Instance Header . . . . . . . . . . . . 13 68 3.4.2. Syntax of FDT Instance . . . . . . . . . . . . . . . . 14 69 3.4.3. Content Encoding of FDT Instance . . . . . . . . . . . 18 70 3.5. Multiplexing of files within a file delivery session . . . 19 71 4. Channels, congestion control and timing . . . . . . . . . . . 19 72 5. Delivering FEC Object Transmission Information . . . . . . . . 20 73 6. Describing file delivery sessions . . . . . . . . . . . . . . 22 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 75 7.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 23 76 7.2. Attacks against the data flow . . . . . . . . . . . . . . 24 77 7.2.1. Access to confidential files . . . . . . . . . . . . . 24 78 7.2.2. File corruption . . . . . . . . . . . . . . . . . . . 24 79 7.3. Attacks against the session control parameters and 80 associated Building Blocks . . . . . . . . . . . . . . . . 25 81 7.3.1. Attacks against the Session Description . . . . . . . 26 82 7.3.2. Attacks against the FDT Instances . . . . . . . . . . 26 83 7.3.3. Attacks against the ALC/LCT parameters . . . . . . . . 27 84 7.3.4. Attacks against the associated Building Blocks . . . . 27 85 7.4. Other Security Considerations . . . . . . . . . . . . . . 28 86 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 87 8.1. Registration Request for XML Schema of FDT Instance . . . 28 88 8.2. Media-Type Registration Request for application/fdt+xml . 28 89 8.3. Content Encoding Algorithm Registration Request . . . . . 30 90 8.3.1. Explicit IANA Assignment Guidelines . . . . . . . . . 30 91 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 92 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 30 93 11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 31 94 11.1. RFC3926 to draft-ietf-rmt-flute-revised-01 . . . . . . . . 31 95 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 96 12.1. Normative references . . . . . . . . . . . . . . . . . . . 32 97 12.2. Informative references . . . . . . . . . . . . . . . . . . 33 98 Appendix A. Receiver operation (informative) . . . . . . . . . . 34 99 Appendix B. Example of FDT Instance (informative) . . . . . . . . 36 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 101 Intellectual Property and Copyright Statements . . . . . . . . . . 38 103 1. Introduction 105 This document defines FLUTE version 1, a protocol for unidirectional 106 delivery of files over the Internet. The specification builds on 107 Asynchronous Layered Coding (ALC), version 1 [2], the base protocol 108 designed for massively scalable multicast distribution. ALC defines 109 transport of arbitrary binary objects. For file delivery 110 applications mere transport of objects is not enough, however. The 111 end systems need to know what the objects actually represent. This 112 document specifies a technique called FLUTE - a mechanism for 113 signaling and mapping the properties of files to concepts of ALC in a 114 way that allows receivers to assign those parameters for received 115 objects. Consequently, throughout this document the term 'file' 116 relates to an 'object' as discussed in ALC. Although this 117 specification frequently makes use of multicast addressing as an 118 example, the techniques are similarly applicable for use with unicast 119 addressing. 121 This document defines a specific transport application of ALC, adding 122 the following specifications: 124 - Definition of a file delivery session built on top of ALC, 125 including transport details and timing constraints. 127 - In-band signalling of the transport parameters of the ALC session. 129 - In-band signalling of the properties of delivered files. 131 - Details associated with the multiplexing of multiple files within 132 a session. 134 This specification is structured as follows. Section 3 begins by 135 defining the concept of the file delivery session. Following that it 136 introduces the File Delivery Table that forms the core part of this 137 specification. Further, it discusses multiplexing issues of 138 transmission objects within a file delivery session. Section 4 139 describes the use of congestion control and channels with FLUTE. 140 Section 5 defines how the Forward Error Correction (FEC) Object 141 Transmission Information is to be delivered within a file delivery 142 session. Section 6 defines the required parameters for describing 143 file delivery sessions in a general case. Section 7 outlines 144 security considerations regarding file delivery with FLUTE. Last, 145 there are two informative appendices. The first appendix describes 146 an envisioned receiver operation for the receiver of the file 147 delivery session. The second appendix gives an example of File 148 Delivery Table. 150 This specification contains part of the definitions necessary to 151 fully specify a Reliable Multicast Transport protocol in accordance 152 with RFC2357. 154 RFC3926 contained a previous version of this specification, which was 155 published in the "Experimental" category. It was the stated intent 156 of the RMT working group to re-submit this specification as an IETF 157 Proposed Standard in due course. 159 This Proposed Standard specification is thus based on RFC3926 updated 160 according to accumulated experience and growing protocol maturity 161 since the publication of RFC3926. Said experience applies both to 162 this specification itself and to congestion control strategies 163 related to the use of this specification. 165 The differences between RFC3926 and this document listed in 166 Section 11. 168 1.1. Applicability Statement 170 1.1.1. The Target Application Space 172 FLUTE is applicable to the delivery of large and small files to many 173 hosts, using delivery sessions of several seconds or more. For 174 instance, FLUTE could be used for the delivery of large software 175 updates to many hosts simultaneously. It could also be used for 176 continuous, but segmented, data such as time-lined text for 177 subtitling - potentially leveraging its layering inheritance from ALC 178 and LCT to scale the richness of the session to the congestion status 179 of the network. It is also suitable for the basic transport of 180 metadata, for example SDP [14] files which enable user applications 181 to access multimedia sessions. 183 1.1.2. The Target Scale 185 Massive scalability is a primary design goal for FLUTE. IP multicast 186 is inherently massively scalable, but the best effort service that it 187 provides does not provide session management functionality, 188 congestion control or reliability. FLUTE provides all of this using 189 ALC and IP multicast without sacrificing any of the inherent 190 scalability of IP multicast. 192 1.1.3. Intended Environments 194 All of the environmental requirements and considerations that apply 195 to the ALC building block [2] and to any additional building blocks 196 that FLUTE uses also apply to FLUTE. 198 FLUTE can be used with both multicast and unicast delivery, but it's 199 primary application is for unidirectional multicast file delivery. 200 FLUTE requires connectivity between a sender and receivers but does 201 not require connectivity from receivers to a sender. FLUTE 202 inherently works with all types of networks, including LANs, WANs, 203 Intranets, the Internet, asymmetric networks, wireless networks, and 204 satellite networks. 206 FLUTE is compatible with both IPv4 or IPv6 as no part of the packet 207 is IP version specific. FLUTE works with both multicast models: Any- 208 Source Multicast (ASM) [15] and the Source-Specific Multicast (SSM) 209 [16]. 211 FLUTE is applicable for both Internet use, with a suitable congestion 212 control building block, and provisioned/controlled systems, such as 213 delivery over wireless broadcast radio systems. 215 1.1.4. Weaknesses 217 Some networks are not amenable to some congestion control protocols 218 that could be used with FLUTE. In particular, for a satellite or 219 wireless network, there may be no mechanism for receivers to 220 effectively reduce their reception rate since there may be a fixed 221 transmission rate allocated to the session. 223 FLUTE provides reliability using the FEC building block. This will 224 reduce the error rate as seen by applications. However, FLUTE does 225 not provide a method for senders to verify the reception success of 226 receivers, and the specification of such a method is outside the 227 scope of this document. 229 2. Conventions used in this Document 231 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 232 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 233 document are to be interpreted as described in RFC 2119 [1]. 235 The terms "object" and "transmission object" are consistent with the 236 definitions in ALC [2] and LCT [3]. The terms "file" and "source 237 object" are pseudonyms for "object". 239 3. File delivery 241 Asynchronous Layered Coding [2] is a protocol designed for delivery 242 of arbitrary binary objects. It is especially suitable for massively 243 scalable, unidirectional, multicast distribution. ALC provides the 244 basic transport for FLUTE, and thus FLUTE inherits the requirements 245 of ALC. 247 This specification is designed for the delivery of files. The core 248 of this specification is to define how the properties of the files 249 are carried in-band together with the delivered files. 251 As an example, let us consider a 5200 byte file referred to by 252 "http://www.example.com/docs/file.txt". Using the example, the 253 following properties describe the properties that need to be conveyed 254 by the file delivery protocol. 256 * Identifier of the file, expressed as a URI. This identifier may 257 be globally unique. The identifier may also provide a location 258 for the file. In the above example: 259 "http://www.example.com/docs/file.txt". 261 * File name (usually, this can be concluded from the URI). In the 262 above example: "file.txt". 264 * File type, expressed as MIME media type (usually, this can also be 265 concluded from the extension of the file name). In the above 266 example: "text/plain". If an explicit value for the MIME type is 267 provided separately from the file extension and does not match the 268 MIME type of the file extension then the explicitly provided value 269 MUST be used as the MIME type. 271 * File size, expressed in bytes. In the above example: "5200". If 272 the file is content encoded then this is the file size before 273 content encoding. 275 * Content encoding of the file, within transport. In the above 276 example, the file could be encoded using ZLIB [12]. In this case 277 the size of the transmission object carrying the file would 278 probably differ from the file size. The transmission object size 279 is delivered to receivers as part of the FLUTE protocol. 281 * Security properties of the file such as digital signatures, 282 message digests, etc. For example, one could use S/MIME [19] as 283 the content encoding type for files with this authentication 284 wrapper, and one could use XML-DSIG [20] to digitally sign an FDT 285 Instance. XML-DSIG can also be used to provide tamper prevention 286 e.g. on the Content-Location field. 288 3.1. File delivery session 290 ALC is a protocol instantiation of Layered Coding Transport building 291 block (LCT) [3]. Thus ALC inherits the session concept of LCT. In 292 this document we will use the concept ALC/LCT session to collectively 293 denote the interchangeable terms ALC session and LCT session. 295 An ALC/LCT session consists of a set of logically grouped ALC/LCT 296 channels associated with a single sender sending packets with ALC/LCT 297 headers for one or more objects. An ALC/LCT channel is defined by 298 the combination of a sender and an address associated with the 299 channel by the sender. A receiver joins a channel to start receiving 300 the data packets sent to the channel by the sender, and a receiver 301 leaves a channel to stop receiving data packets from the channel. 303 One of the fields carried in the ALC/LCT header is the Transport 304 Session Identifier (TSI). The TSI is scoped by the source IP 305 address, and the (source IP address, TSI) pair uniquely identifies a 306 session, i.e., the receiver uses this pair carried in each packet to 307 uniquely identify from which session the packet was received. In 308 case multiple objects are carried within a session, the Transmission 309 Object Identifier (TOI) field within the ALC/LCT header identifies 310 from which object the data in the packet was generated. Note that 311 each object is associated with a unique TOI within the scope of a 312 session. 314 If the sender is not assigned a permanent IP address accessible to 315 receivers, but instead, packets that can be received by receivers 316 containing a temporary IP address for packets sent by the sender, 317 then the TSI is scoped by this temporary IP address of the sender for 318 the duration of the session. As an example, the sender may be behind 319 a Network Address Translation (NAT) device that temporarily assigns 320 an IP address for the sender that is accessible to receivers, and in 321 this case the TSI is scoped by the temporary IP address assigned by 322 the NAT that will appear in packets received by the receiver. As 323 another example, the sender may send its original packets using IPv6, 324 but some portions of the network may not be IPv6 capable and thus 325 there may be an IPv6 to IPv4 translator that changes the IP address 326 of the packets to a different IPv4 address. In this case, receivers 327 in the IPv4 portion of the network will receive packets containing 328 the IPv4 address, and thus the TSI for them is scoped by the IPv4 329 address. How the IP address of the sender to be used to scope the 330 session by receivers is delivered to receivers, whether it is a 331 permanent IP address or a temporary IP address, is outside the scope 332 of this document. 334 When FLUTE is used for file delivery over ALC the following rules 335 apply: 337 * The ALC/LCT session is called file delivery session. 339 * The ALC/LCT concept of 'object' denotes either a 'file' or a 'File 340 Delivery Table Instance' (section 3.2) 342 * The TOI field MUST be included in ALC packets sent within a FLUTE 343 session, with the exception that ALC packets sent in a FLUTE 344 session with the Close Session (A) flag set to 1 (signaling the 345 end of the session) and that contain no payload (carrying no 346 information for any file or FDT) SHALL NOT carry the TOI. See 347 Section 5.1 of RFC 3451 [3] for the LCT definition of the Close 348 Session flag, and see Section 4.2 of RFC 3450 [2] for an example 349 of its use within an ALC packet. 351 * The TOI value '0' is reserved for delivery of File Delivery Table 352 Instances. Each File Delivery Table Instance is uniquely 353 identified by an FDT Instance ID. 355 * Each file in a file delivery session MUST be associated with a TOI 356 (>0) in the scope of that session. 358 * Information carried in the headers and the payload of a packet is 359 scoped by the source IP address and the TSI. Information 360 particular to the object carried in the headers and the payload of 361 a packet is further scoped by the TOI for file objects, and is 362 further scoped by both the TOI and the FDT Instance ID for FDT 363 Instance objects. 365 3.2. File Delivery Table 367 The File Delivery Table (FDT) provides a means to describe various 368 attributes associated with files that are to be delivered within the 369 file delivery session. The following lists are examples of such 370 attributes, and are not intended to be mutually exclusive nor 371 exhaustive. 373 Attributes related to the delivery of file: 375 - TOI value that represents the file 377 - FEC Object Transmission Information (including the FEC Encoding ID 378 and, if relevant, the FEC Instance ID) 380 - Size of the transmission object carrying the file 382 - Aggregate rate of sending packets to all channels 384 Attributes related to the file itself: 386 - Name, Identification and Location of file (specified by the URI) 388 - MIME media type of file 390 - Size of file 392 - Encoding of file 394 - Message digest of file 396 Some of these attributes MUST be included in the file description 397 entry for a file, others are optional, as defined in section 3.4.2. 399 Logically, the FDT is a set of file description entries for files to 400 be delivered in the session. Each file description entry MUST 401 include the TOI for the file that it describes and the URI 402 identifying the file. The TOI is included in each ALC/LCT data 403 packet during the delivery of the file, and thus the TOI carried in 404 the file description entry is how the receiver determines which ALC/ 405 LCT data packets contain information about which file. Each file 406 description entry may also contain one or more descriptors that map 407 the above-mentioned attributes to the file. 409 Each file delivery session MUST have an FDT that is local to the 410 given session. The FDT MUST provide a file description entry mapped 411 to a TOI for each file appearing within the session. An object that 412 is delivered within the ALC session, but not described in the FDT, is 413 not considered a 'file' belonging to the file delivery session. 414 Handling of these unmapped TOIs (TOIs that are not resolved by the 415 FDT) is out of scope of this specification. 417 Within the file delivery session the FDT is delivered as FDT 418 Instances. An FDT Instance contains one or more file description 419 entries of the FDT. Any FDT Instance can be equal to, a subset of, a 420 superset of, or complement any other FDT Instance. A certain FDT 421 Instance may be repeated several times during a session, even after 422 subsequent FDT Instances (with higher FDT Instance ID numbers) have 423 been transmitted. Each FDT Instance contains at least a single file 424 description entry and at most the exhaustive set of file description 425 entries of the files being delivered in the file delivery session. 427 A receiver of the file delivery session keeps an FDT database for 428 received file description entries. The receiver maintains the 429 database, for example, upon reception of FDT Instances. Thus, at any 430 given time the contents of the FDT database represent the receiver's 431 current view of the FDT of the file delivery session. Since each 432 receiver behaves independently of other receivers, it SHOULD NOT be 433 assumed that the contents of the FDT database are the same for all 434 the receivers of a given file delivery session. 436 Since FDT database is an abstract concept, the structure and the 437 maintaining of the FDT database are left to individual 438 implementations and are thus out of scope of this specification. 440 3.3. Dynamics of FDT Instances within file delivery session 442 The following rules define the dynamics of the FDT Instances within a 443 file delivery session: 445 * For every file delivered within a file delivery session there MUST 446 be a file description entry included in at least one FDT Instance 447 sent within the session. A file description entry contains at a 448 minimum the mapping between the TOI and the URI. 450 * An FDT Instance MAY appear in any part of the file delivery 451 session and packets for an FDT Instance MAY be interleaved with 452 packets for other files or other FDT Instances within a session. 454 * The TOI value of '0' MUST be reserved for delivery of FDT 455 Instances. The use of other TOI values for FDT Instances is 456 outside the scope of this specification. 458 * FDT Instance is identified by the use of a new fixed length LCT 459 Header Extension EXT_FDT (defined later in this section). Each 460 FDT Instance is uniquely identified within the file delivery 461 session by its FDT Instance ID. Any ALC/LCT packet carrying FDT 462 Instance (indicated by TOI = 0) MUST include EXT_FDT. 464 * It is RECOMMENDED that FDT Instance that contains the file 465 description entry for a file is sent prior to the sending of the 466 described file within a file delivery session. 468 * Within a file delivery session, any TOI > 0 MAY be described more 469 than once. An example: previous FDT Instance 0 describes TOI of 470 value '3'. Now, subsequent FDT Instances can either keep TOI '3' 471 unmodified on the table, not include it, or complement the 472 description. However, subsequent FDT Instances MUST NOT change 473 the parameters already described for a specific TOI. 475 * An FDT Instance is valid until its expiration time. The 476 expiration time is expressed within the FDT Instance payload as a 477 32 bit data field. The value of the data field represents the 32 478 most significant bits of a 64 bit Network Time Protocol (NTP) [5] 479 time value. These 32 bits provide an unsigned integer 480 representing the time in seconds relative to 0 hours 1 January 481 1900. Handling of wraparound of the 32 bit time is outside the 482 scope of NTP and FLUTE. 484 * The receiver SHOULD NOT use a received FDT Instance to interpret 485 packets received beyond the expiration time of the FDT Instance. 487 * A sender MUST use an expiry time in the future upon creation of an 488 FDT Instance relative to its Sender Current Time (SCT). 490 * Any FEC Encoding ID MAY be used for the sending of FDT Instances. 491 The default is to use FEC Encoding ID 0 for the sending of FDT 492 Instances. (Note that since FEC Encoding ID 0 is the default for 493 FLUTE, this implies that Source Block Number and Encoding Symbol 494 ID lengths both default to 16 bits each.) 496 Generally, a receiver needs to receive an FDT Instance describing a 497 file before it is able to recover the file itself. In this sense FDT 498 Instances are of higher priority than files. Thus, it is RECOMMENDED 499 that FDT Instances describing a file be sent with at least as much 500 reliability within a session (more often or with more FEC protection) 501 as the files they describe. In particular, if FDT Instances are 502 longer than one packet payload in length it is RECOMMENDED that an 503 FEC code that provides protection against loss be used for delivering 504 FDT Instances. How often the description of a file is sent in an FDT 505 Instance or how much FEC protection is provided for each FDT Instance 506 (if the FDT Instance is longer than one packet payload) is dependent 507 on the particular application and outside the scope of this document. 509 3.4. Structure of FDT Instance packets 511 FDT Instances are carried in ALC packets with TOI = 0 and with an 512 additional REQUIRED LCT Header extension called the FDT Instance 513 Header. The FDT Instance Header (EXT_FDT) contains the FDT Instance 514 ID that uniquely identifies FDT Instances within a file delivery 515 session. The FDT Instance Header is placed in the same way as any 516 other LCT extension header. There MAY be other LCT extension headers 517 in use. 519 The LCT extension headers are followed by the FEC Payload ID, and 520 finally the Encoding Symbols for the FDT Instance which contains one 521 or more file description entries. A FDT Instance MAY span several 522 ALC packets - the number of ALC packets is a function of the file 523 attributes associated with the FDT Instance. The FDT Instance Header 524 is carried in each ALC packet carrying the FDT Instance. The FDT 525 Instance Header is identical for all ALC/LCT packets for a particular 526 FDT Instance. 528 The overall format of ALC/LCT packets carrying an FDT Instance is 529 depicted in the Figure 1 below. All integer fields are carried in 530 "big-endian" or "network order" format, that is, most significant 531 byte (octet) first. As defined in [2], all ALC/LCT packets are sent 532 using UDP. 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | UDP header | 536 | | 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 | Default LCT header (with TOI = 0) | 539 | | 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 | LCT header extensions (EXT_FDT, EXT_FTI, etc.) | 542 | | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 | FEC Payload ID | 545 | | 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 FLUTE Payload: Encoding Symbol(s) 548 ~ (for FDT Instance in a FDT packet) ~ 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 Figure 1: Overall FDT Packet 554 3.4.1. Format of FDT Instance Header 556 FDT Instance Header (EXT_FDT) is a new fixed length, ALC PI specific 557 LCT header extension [3]. The Header Extension Type (HET) for the 558 extension is 192. Its format is defined below: 560 0 1 2 3 561 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 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | HET = 192 | V | FDT Instance ID | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 Figure 2 568 Version of FLUTE (V), 4 bits: 570 This document specifies FLUTE version 1. Hence in any ALC packet 571 that carries FDT Instance and that belongs to the file delivery 572 session as specified in this specification MUST set this field to 573 '1'. 575 FDT Instance ID, 20 bits: 577 For each file delivery session the numbering of FDT Instances starts 578 from '0' and is incremented by one for each subsequent FDT Instance. 579 After reaching the maximum value (2^20-1), the numbering starts from 580 the smallest FDT Instance value assigned to an expired FDT Instance. 581 When wraparound from a greater FDT Instance value to a smaller FDT 582 Instance value occurs, the smaller FDT Instance value is considered 583 logically higher than the greater FDT Instance value. A new FDT 584 Instance reusing a previous FDT Instance ID number, due to 585 wraparound, may not implicitly expire the previous FDT Instance with 586 the same ID. Mandatory receiver behavior for handling FDT Instance 587 ID wraparound and other special situations (for example, missing FDT 588 Instance IDs resulting in larger increments than one) is outside the 589 scope of this specification and left to individual implementations of 590 FLUTE. 592 3.4.2. Syntax of FDT Instance 594 The FDT Instance contains file description entries that provide the 595 mapping functionality described in 3.2 above. 597 The FDT Instance is an XML structure that has a single root element 598 "FDT-Instance". The "FDT-Instance" element MUST contain "Expires" 599 attribute, which tells the expiry time of the FDT Instance. In 600 addition, the "FDT-Instance" element MAY contain the "Complete" 601 attribute (boolean), which, when TRUE, signals that this "FDT 602 Instance" includes the set of "File" entries that exhausts both the 603 set of files delivered so far and also the set of files to be 604 delivered in the session. This implies that no new data will be 605 provided in future FDT Instances within this session (i.e., that 606 either FDT Instances with higher ID numbers will not be used or if 607 they are used, will only provide identical file parameters to those 608 already given in this and previous FDT Instances). The "Complete" 609 attribute is therefore used to provide a complete list of files in an 610 entire FLUTE session (a "complete FDT"). 612 The "FDT-Instance" element MAY contain attributes that give common 613 parameters for all files of an FDT Instance. These attributes MAY 614 also be provided for individual files in the "File" element. Where 615 the same attribute appears in both the "FDT-Instance" and the "File" 616 elements, the value of the attribute provided in the "File" element 617 takes precedence. 619 For each file to be declared in the given FDT Instance there is a 620 single file description entry in the FDT Instance. Each entry is 621 represented by element "File" which is a child element of the FDT 622 Instance structure. 624 The attributes of "File" element in the XML structure represent the 625 attributes given to the file that is delivered in the file delivery 626 session. The value of the XML attribute name corresponds to MIME 627 field name and the XML attribute value corresponds to the value of 628 the MIME field body. Each "File" element MUST contain at least two 629 attributes "TOI" and "Content-Location". "TOI" MUST be assigned a 630 valid TOI value as described in section 3.3 above. "Content- 631 Location" MUST be assigned a valid URI as defined in [6]. The 632 semantics for any two "File" elements declaring the same "Content- 633 Location" but differing "TOI" is that the element appearing in the 634 FDT Instance with the greater FDT Instance ID is considered to 635 declare newer instance (e.g. version) of the same "File". 637 In addition to mandatory attributes, the "FDT-Instance" element and 638 the "File" element MAY contain other attributes of which the 639 following are specifically pointed out. 641 * Where the MIME type is described, the attribute "Content-Type" 642 MUST be used for the purpose as defined in [6]. 644 * Where the length is described, the attribute "Content-Length" MUST 645 be used for the purpose as defined in [6]. The transfer length is 646 defined to be the length of the object transported in bytes. It 647 is often important to convey the transfer length to receivers, 648 because the source block structure needs to be known for the FEC 649 decoder to be applied to recover source blocks of the file, and 650 the transfer length is often needed to properly determine the 651 source block structure of the file. There generally will be a 652 difference between the length of the original file and the 653 transfer length if content encoding is applied to the file before 654 transport, and thus the "Content-Encoding" attribute is used. If 655 the file is not content encoded before transport (and thus the 656 "Content-Encoding" attribute is not used) then the transfer length 657 is the length of the original file, and in this case the "Content- 658 Length" is also the transfer length. However, if the file is 659 content encoded before transport (and thus the "Content-Encoding" 660 attribute is used), e.g., if compression is applied before 661 transport to reduce the number of bytes that need to be 662 transferred, then the transfer length is generally different than 663 the length of the original file, and in this case the attribute 664 "Transfer-Length" MAY be used to carry the transfer length. 666 * Where the content encoding scheme is described, the attribute 667 "Content-Encoding" MUST be used for the purpose as defined in [6]. 669 * Where the MD5 message digest is described, the attribute "Content- 670 MD5" MUST be used for the purpose as defined in [6]. 672 * The FEC Object Transmission Information attributes as described in 673 section 5.2. 675 The following specifies the XML Schema [7][8] for FDT Instance: 677 BEGIN 678 679 683 684 685 686 687 689 690 693 696 699 702 705 708 711 714 717 721 722 723 724 725 727 728 731 734 737 740 743 746 749 752 755 758 761 764 767 768 770 771 END 773 Figure 3 775 Any valid FDT Instance must use the above XML Schema. This way FDT 776 provides extensibility to support private attributes within the file 777 description entries. Those could be, for example, the attributes 778 related to the delivery of the file (timing, packet transmission 779 rate, etc.). 781 In case the basic FDT XML Schema is extended in terms of new 782 descriptors (attributes or elements), for descriptors applying to a 783 single file, those MUST be placed within the element "File". For 784 descriptors applying to all files described by the current FDT 785 Instance, those MUST be placed within the element "FDT-Instance". It 786 is RECOMMENDED that the new attributes applied in the FDT are in the 787 format of MIME fields and are either defined in the HTTP/1.1 788 specification [6] or another well-known specification. 790 3.4.3. Content Encoding of FDT Instance 792 The FDT Instance itself MAY be content encoded, for example 793 compressed. This specification defines FDT Instance Content Encoding 794 Header (EXT_CENC). EXT_CENC is a new fixed length, ALC PI specific 795 LCT header extension [3]. The Header Extension Type (HET) for the 796 extension is 193. If the FDT Instance is content encoded, the 797 EXT_CENC MUST be used to signal the content encoding type. In that 798 case, EXT_CENC header extension MUST be used in all ALC packets 799 carrying the same FDT Instance ID. Consequently, when EXT_CENC 800 header is used, it MUST be used together with a proper FDT Instance 801 Header (EXT_FDT). Within a file delivery session, FDT Instances that 802 are not content encoded and FDT Instances that are content encoded 803 MAY both appear. If content encoding is not used for a given FDT 804 Instance, the EXT_CENC MUST NOT be used in any packet carrying the 805 FDT Instance. The format of EXT_CENC is defined below: 807 0 1 2 3 808 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 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 | HET = 193 | CENC | Reserved | 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 Figure 4 815 Content Encoding Algorithm (CENC), 8 bits: 817 This field signals the content encoding algorithm used in the FDT 818 Instance payload. This subsection reserves the Content Encoding 819 Algorithm values 0, 1, 2 and 3 for null, ZLIB [12], DEFLATE [17] and 820 GZIP [18] respectively. 822 Reserved, 16 bits: 824 This field MUST be set to all '0'. 826 3.5. Multiplexing of files within a file delivery session 828 The delivered files are carried as transmission objects (identified 829 with TOIs) in the file delivery session. All these objects, 830 including the FDT Instances, MAY be multiplexed in any order and in 831 parallel with each other within a session, i.e., packets for one file 832 MAY be interleaved with packets for other files or other FDT 833 Instances within a session. 835 Multiple FDT Instances MAY be delivered in a single session using TOI 836 = 0. In this case, it is RECOMMENDED that the sending of a previous 837 FDT Instance SHOULD end before the sending of the next FDT Instance 838 starts. However, due to unexpected network conditions, packets for 839 the FDT Instances MAY be interleaved. A receiver can determine which 840 FDT Instance a packet contains information about since the FDT 841 Instances are uniquely identified by their FDT Instance ID carried in 842 the EXT_FDT headers. 844 4. Channels, congestion control and timing 846 ALC/LCT has a concept of channels and congestion control. There are 847 four scenarios FLUTE is envisioned to be applied. 849 (a) Use a single channel and a single-rate congestion control 850 protocol. 852 (b) Use multiple channels and a multiple-rate congestion control 853 protocol. In this case the FDT Instances MAY be delivered on more 854 than one channel. 856 (c) Use a single channel without congestion control supplied by ALC, 857 but only when in a controlled network environment where flow/ 858 congestion control is being provided by other means. 860 (d) Use multiple channels without congestion control supplied by 861 ALC, but only when in a controlled network environment where flow/ 862 congestion control is being provided by other means. In this case 863 the FDT Instances MAY be delivered on more than one channel. 865 When using just one channel for a file delivery session, as in (a) 866 and (c), the notion of 'prior' and 'after' are intuitively defined 867 for the delivery of objects with respect to their delivery times. 869 However, if multiple channels are used, as in (b) and (d), it is not 870 straightforward to state that an object was delivered 'prior' to the 871 other. An object may begin to be delivered on one or more of those 872 channels before the delivery of a second object begins. However, the 873 use of multiple channels/layers may complete the delivery of the 874 second object before the first. This is not a problem when objects 875 are delivered sequentially using a single channel. Thus, if the 876 application of FLUTE has a mandatory or critical requirement that the 877 first transmission object must complete 'prior' to the second one, it 878 is RECOMMENDED that only a single channel is used for the file 879 delivery session. 881 Furthermore, if multiple channels are used then a receiver joined to 882 the session at a low reception rate will only be joined to the lower 883 layers of the session. Thus, since the reception of FDT Instances is 884 of higher priority than the reception of files (because the reception 885 of files depends on the reception of an FDT Instance describing it), 886 the following is RECOMMENDED: 888 1. The layers to which packets for FDT Instances are sent SHOULD NOT 889 be biased towards those layers to which lower rate receivers are 890 not joined. For example, it is ok to put all the packets for an 891 FDT Instance into the lowest layer (if this layer carries enough 892 packets to deliver the FDT to higher rate receivers in a 893 reasonable amount of time), but it is not ok to put all the 894 packets for an FDT Instance into the higher layers that only high 895 rate receivers will receive. 897 2. If FDT Instances are generally longer than one Encoding Symbol in 898 length and some packets for FDT Instances are sent to layers that 899 lower rate receivers do not receive, an FEC Encoding other than 900 FEC Encoding ID 0 SHOULD be used to deliver FDT Instances. This 901 is because in this case, even when there is no packet loss in the 902 network, a lower rate receiver will not receive all packets sent 903 for an FDT Instance. 905 5. Delivering FEC Object Transmission Information 907 FLUTE inherits the use of FEC building block [4] from ALC. When 908 using FLUTE for file delivery over ALC the FEC Object Transmission 909 Information MUST be delivered in-band within the file delivery 910 session. There are two methods to achieve this: the use of ALC 911 specific LCT extension header EXT_FTI [2] and the use of FDT. The 912 latter method is specified in this section. 914 The receiver of file delivery session MUST support delivery of FEC 915 Object Transmission Information using the EXT_FTI for the FDT 916 Instances carried using TOI value 0. For the TOI values other than 0 917 the receiver MUST support both methods: the use of EXT_FTI and the 918 use of FDT. 920 The FEC Object Transmission Information that needs to be delivered to 921 receivers MUST be exactly the same whether it is delivered using 922 EXT_FTI or using FDT (or both). The FEC Object Transmission 923 Information that MUST be delivered to receivers is defined by the FEC 924 Scheme. This section describes the delivery using FDT. 926 The FEC Object Transmission Information regarding a given TOI may be 927 available from several sources. In this case, it is RECOMMENDED that 928 the receiver of the file delivery session prioritizes the sources in 929 the following way (in the order of decreasing priority). 931 1. FEC Object Transmission Information that is available in EXT_FTI. 933 2. FEC Object Transmission Information that is available in the FDT. 935 The FDT delivers FEC Object Transmission Information for each file 936 using an appropriate attribute within the "FDT-Instance" or the 937 "File" element of the FDT structure. 939 * "Transfer-Length" carries the Transfer-Length Object Transmission 940 Information element defined in [4]. 942 * "FEC-OTI-FEC-Encoding-ID" carries the "FEC Encoding ID" Object 943 Transmission Information element defined in [4], as carried in the 944 Codepoint field of the ALC/LCT header. 946 * "FEC-OTI-FEC-Instance-ID" carries the "FEC Instance ID" Object 947 Transmission Information element defined in [4] for Under- 948 specified FEC Schemes. 950 * "FEC-OTI-Maximum-Source-Block-Length" carries the "Maximum Source 951 Block Length" Object Transmission Information element defined in 952 [4], if required by the FEC Scheme. 954 * "FEC-OTI-Encoding-Symbol-Length" carries the "Encoding Symbol 955 Length" Object Transmission Information element defined in [4], if 956 required by the FEC Scheme. 958 * "FEC-OTI-Max-Number-of-Encoding-Symbols" carries the "Maximum 959 Number of Encoding Symbols" Object Transmission Information 960 element defined in [4], if required by the FEC Scheme. 962 * "FEC-OTI-Scheme-specific-information" carries the "encoded scheme- 963 specific FEC Object Transmission Information" as defined in [4], 964 if required by the FEC Scheme. 966 In FLUTE, the FEC Encoding ID (8 bits) for a given TOI MUST be 967 carried in the Codepoint field of the ALC/LCT header. When the FEC 968 Object Transmission Information for this TOI is delivered through the 969 FDT, then the associated "FEC-OTI-FEC-Encoding-ID" attribute and the 970 Codepoint field of all packets for this TOI MUST be the same. 972 6. Describing file delivery sessions 974 To start receiving a file delivery session, the receiver needs to 975 know transport parameters associated with the session. Interpreting 976 these parameters and starting the reception therefore represents the 977 entry point from which thereafter the receiver operation falls into 978 the scope of this specification. According to [2], the transport 979 parameters of an ALC/LCT session that the receiver needs to know are: 981 * The source IP address; 983 * The number of channels in the session; 985 * The destination IP address and port number for each channel in the 986 session; 988 * The Transport Session Identifier (TSI) of the session; 990 * An indication that the session is a FLUTE session. The need to 991 demultiplex objects upon reception is implicit in any use of 992 FLUTE, and this fulfills the ALC requirement of an indication of 993 whether or not a session carries packets for more than one object 994 (all FLUTE sessions carry packets for more than one object). 996 Optionally, the following parameters MAY be associated with the 997 session (Note, the list is not exhaustive): 999 * The start time and end time of the session; 1001 * FEC Encoding ID and FEC Instance ID when the default FEC Encoding 1002 ID 0 is not used for the delivery of FDT; 1004 * Content Encoding format if optional content encoding of FDT 1005 Instance is used, e.g., compression; 1007 * Some information that tells receiver, in the first place, that the 1008 session contains files that are of interest. 1010 It is envisioned that these parameters would be described according 1011 to some session description syntax (such as SDP [14] or XML based) 1012 and held in a file which would be acquired by the receiver before the 1013 FLUTE session begins by means of some transport protocol (such as 1014 Session Announcement Protocol [13], email, HTTP [6], SIP [22], manual 1015 pre-configuration, etc.) However, the way in which the receiver 1016 discovers the above-mentioned parameters is out of scope of this 1017 document, as it is for LCT and ALC. In particular, this 1018 specification does not mandate or exclude any mechanism. 1020 7. Security Considerations 1022 7.1. Problem Statement 1024 A content delivery system is potentially subject to attacks. Attacks 1025 may target: 1027 * the network (to compromise the routing infrastructure, e.g., by 1028 creating congestion), 1030 * the Content Delivery Protocol (CDP) (e.g., to compromise the 1031 normal behaviour of FLUTE) or 1033 * the content itself (e.g., to corrupt the files being transmitted). 1035 These attacks can be launched either: 1037 * against the data flow itself (e.g., by sending forged symbols), 1039 * against the session control parameters, (e.g., by corrupting the 1040 session description, the FDT Instances, or the ALC/LCT control 1041 parameters), that are sent either in-band or out-of-band or 1043 * against some associated building blocks (e.g., the congestion 1044 control component). 1046 In the following sections we provide more details on these possible 1047 attacks and sketch some possible counter-measures. 1049 7.2. Attacks against the data flow 1051 Let us consider attacks against the data flow first. At least, the 1052 following types of attacks exist: 1054 * attacks that are meant to give access to a confidential file 1055 (e.g., in case of a non-free content) and 1057 * attacks that try to corrupt the file being transmitted (e.g., to 1058 inject malicious code within a file, or to prevent a receiver from 1059 using a file, which is a kind of Denial of Service, DoS). 1061 7.2.1. Access to confidential files 1063 Access control to the file being transmitted is typically provided by 1064 means of encryption. This encryption can be done over the whole file 1065 (e.g., by the content provider, before submitting the file to FLUTE), 1066 or be done on a packet per packet basis (e.g., when IPSec/ESP is used 1067 [26]). If access control is a concern, it is RECOMMENDED that one of 1068 these solutions be used. 1070 7.2.2. File corruption 1072 Protection against corruptions (e.g., after sending forged packets) 1073 is achieved by means of a content integrity verification/sender 1074 authentication scheme. This service can be provided at the file 1075 level, but in that case a receiver has no way to identify which 1076 symbol(s) is(are) corrupted if the file is detected as corrupted. 1077 This service can also be provided at the packet level. In this case, 1078 after removing all corrupted packets, the file may be in some cases 1079 recovered. Several techniques can provide this source 1080 authentication/content integrity service: 1082 * at the file level, the file MAY be digitally signed (with public 1083 key cryptography), for instance by using RSASSA-PKCS1-v1_5 [24]. 1084 This signature enables a receiver to check the file integrity, 1085 once this latter has been fully decoded. Even if digital 1086 signatures are computationally expensive, this calculation occurs 1087 only once per file, which is usually acceptable; 1089 * at the packet level, each packet can be digitally signed. A major 1090 limitation is the high computational and transmission overheads 1091 that this solution requires. To avoid this problem, the signature 1092 may span a set of symbols (instead of a single one) in order to 1093 amortize the signature calculation, but if a single symbol is 1094 missing, the integrity of the whole set cannot be checked; 1096 * at the packet level, a Group Message Authentication Code (MAC) 1097 [27] scheme can be used, for instance by using HMAC-SHA-1 with a 1098 secret key shared by all the group members, senders and receivers. 1099 This technique creates a cryptographically secured digest of a 1100 packet that is sent along with the packet. The Group MAC scheme 1101 does not create prohibitive processing load nor transmission 1102 overhead, but it has a major limitation: it only provides a group 1103 authentication/integrity service since all group members share the 1104 same secret group key, which means that each member can send a 1105 forged packet. It is therefore restricted to situations where 1106 group members are fully trusted (or in association with another 1107 technique as a pre-check); 1109 * at the packet level, TESLA [28]] is a very attractive and 1110 efficient solution that is robust to losses, provides a true 1111 authentication/integrity service, and does not create any 1112 prohibitive processing load or transmission overhead. Yet 1113 checking a packet requires a small delay (a second or more) after 1114 its reception; or; 1116 * at the packet level, IPSec/AH [25] (possibly associated to IPSec/ 1117 ESP) can be used to protect all the packets being exchanged in a 1118 session. 1120 Techniques relying on public key cryptography (digital signatures and 1121 TESLA during the bootstrap process, when used) require that public 1122 keys be securely associated to the entities. This can be achieved by 1123 a Public Key Infrastructure (PKI), or by a PGP Web of Trust, or by 1124 pre-distributing the public keys of each group member. 1126 Techniques relying on symmetric key cryptography (Group MAC) require 1127 that a secret key be shared by all group members. This can be 1128 achieved by means of a group key management protocol, or simply by 1129 pre-distributing the secret key (but this manual solution has many 1130 limitations). 1132 It is up to the developer and deployer, who know the security 1133 requirements and features of the target application area, to define 1134 which solution is the most appropriate. Nonetheless, in case there 1135 is any concern of the threat of file corruption, it is RECOMMENDED 1136 that at least one of these techniques be used. 1138 7.3. Attacks against the session control parameters and associated 1139 Building Blocks 1141 Let us now consider attacks against the session control parameters 1142 and the associated building blocks. The attacker has at least the 1143 following opportunities to launch an attack: 1145 * the attack can target the session description, 1147 * the attack can target the FDT Instances, 1149 * the attack can target the ALC/LCT parameters, carried within the 1150 LCT header or 1152 * the attack can target the FLUTE associated building blocks. 1154 The latter one is particularly true with the multiple rate congestion 1155 control protocol which may be required. 1157 The consequences of these attacks are potentially serious, since they 1158 might compromise the behavior of content delivery system. 1160 7.3.1. Attacks against the Session Description 1162 A FLUTE receiver may potentially obtain an incorrect Session 1163 Description for the session. The consequence of this is that 1164 legitimate receivers with the wrong Session Description are unable to 1165 correctly receive the session content, or that receivers 1166 inadvertently try to receive at a much higher rate than they are 1167 capable of, thereby possibly disrupting other traffic in the network. 1169 To avoid these problems, it is RECOMMENDED that measures be taken to 1170 prevent receivers from accepting incorrect Session Descriptions. One 1171 such measure is source authentication to ensure that receivers only 1172 accept legitimate Session Descriptions from authorized senders. How 1173 these measures are achived is outside the scope of this document 1174 since this session description is usually carried out-of-band. 1176 7.3.2. Attacks against the FDT Instances 1178 Corrupting the FDT Instances is one way to create a Denial of Service 1179 attack. For example, the attacker changes the MD5 sum associated to 1180 a file. This possibly leads a receiver to reject the files received, 1181 no matter whether the files have been correctly received or not. 1183 Corrupting the FDT Instances is also a way to make the reception 1184 process more costly than it should be. This can be achieved by 1185 changing the FEC Object Transmission Information when the FEC Object 1186 Transmission Information is included in the FDT Instance. For 1187 example, an attacker may corrupt the FDT Instance in such a way that 1188 Reed-Solomon over GF(2^^16) be used instead of GF(2^^8) with FEC 1189 Encoding ID 2. This may significantly increase the processing load 1190 while compromising FEC decoding. 1192 It is therefore RECOMMENDED that measures be taken to guarantee the 1193 integrity and to check the sender's identity of the FDT Instances. 1194 To that purpose, one of the counter-measures mentioned above 1195 (Section 7.2.2) SHOULD be used. These measures will either be 1196 applied on a packet level, or globally over the whole FDT Instance 1197 object. Additionally, XML digital signatures [20] are a way to 1198 protect the FDT Instance by digitally signing it. When there is no 1199 packet level integrity verification scheme, it is RECOMMENDED to rely 1200 on XML digital signatures of the FDT Instances. 1202 7.3.3. Attacks against the ALC/LCT parameters 1204 By corrupting the ALC/LCT header (or header extensions) one can 1205 execute attacks on underlying ALC/LCT implementation. For example, 1206 by sending forged ALC packets with the Close Session flag (A) set one 1207 can lead the receiver to prematurely close the session. Similarly, 1208 by sending forged ALC packets with the Close Object flag (B) set one 1209 can lead the receiver to prematurely give up the reception of an 1210 object. 1212 It is therefore RECOMMENDED that measures be taken to guarantee the 1213 integrity and to check the sender's identity of the ALC packets 1214 received. To that purpose, one of the counter-measures mentioned 1215 above (Section 7.2.2) SHOULD be used. 1217 7.3.4. Attacks against the associated Building Blocks 1219 Let us first focus on the congestion control building block, that is 1220 may be associated to FLUTE. A receiver with an incorrect or 1221 corrupted implementation of the multiple rate congestion control 1222 building block may affect the health of the network in the path 1223 between the sender and the receiver. That may also affect the 1224 reception rates of other receivers who joined the session. 1226 When congestion control building block is applied with FLUTE, it is 1227 therefore RECOMMENDED that receivers be required to identify 1228 themselves as legitimate before they receive the Session Description 1229 needed to join the session. How receivers identify themselves as 1230 legitimate is outside the scope of this document. If authenticating 1231 a receiver does not prevent this latter to launch an attack, it will 1232 enable the network operator to identify him and to take counter- 1233 measures. 1235 When congestion control building block is applied with FLUTE, it is 1236 also RECOMMENDED that a packet level authentication scheme be used, 1237 as explained in Section 7.2.2. Some of them, like TESLA, only 1238 provide a delayed authentication service, whereas congestion control 1239 requires a rapid reaction. It is therefore RECOMMENDED [2] that a 1240 receiver using TESLA quickly reduces its subscription level when the 1241 receiver believes that a congestion did occur, even if the packet has 1242 not yet been authenticated. Therefore TESLA will not prevent DoS 1243 attacks where an attacker makes the receiver believe that a 1244 congestion occurred. This is an issue for the receiver, but this 1245 will not compromise the network since no congestion actually 1246 occurred. Other authentication methods that do not feature this 1247 delayed authentication could be prefered, or a group MAC scheme could 1248 be used in parallel to TESLA. 1250 7.4. Other Security Considerations 1252 Lastly, we note that the security considerations that apply to, and 1253 are described in, ALC [2], LCT [3] and FEC [4] also apply to FLUTE as 1254 FLUTE builds on those specifications. In addition, any security 1255 considerations that apply to any congestion control building block 1256 used in conjunction with FLUTE also apply to FLUTE. 1258 8. IANA Considerations 1260 This specification contains three separate items for IANA 1261 Considerations: 1263 1. Registration Request for XML Schema of FDT Instance 1264 (urn:ietf:params:xml:schema:fdt). 1266 2. Media-Type Registration Request for application/fdt+xml. 1268 3. Content Encoding Algorithm Registration Request (ietf:rmt:cenc). 1270 8.1. Registration Request for XML Schema of FDT Instance 1272 Document [23] defines an IANA maintained registry of XML documents 1273 used within IETF protocols. The following is the registration 1274 request for the FDT XML schema. 1276 URI: urn:ietf:params:xml:schema:fdt 1278 Registrant Contact: Toni Paila (toni.paila (at) nokia.com) 1280 XML: The XML Schema specified in Section 3.4.2 1282 8.2. Media-Type Registration Request for application/fdt+xml 1284 This section provides the registration request, as per [21] and [9], 1285 to be submitted to IANA following IESG approval. 1287 Type name: application 1288 Subtype name: fdt+xml 1290 Required parameters: none 1292 Optional parameters: none 1294 Encoding considerations: The fdt+xml type consists of UTF-8 ASCII 1295 characters [10] and must be well-formed XML. 1297 Additional content and transfer encodings may be used with fdt+xml 1298 files, with the appropriate encoding for any specific file being 1299 entirely dependant upon the deployed application. 1301 Restrictions on usage: Only for usage with FDT Instances which are 1302 valid according to the XML schema of section 3.4.2. 1304 Security considerations: fdt+xml data is passive, and does not 1305 generally represent a unique or new security threat. However, there 1306 is some risk in sharing any kind of data, in that unintentional 1307 information may be exposed, and that risk applies to fdt+xml data as 1308 well. 1310 Interoperability considerations: None 1312 Published specification: The present document including section 1313 3.4.2. The specified FDT Instance functions as an actual media 1314 format of use to the general Internet community and thus media type 1315 registration under the Standards Tree is appropriate to maximize 1316 interoperability. 1318 Applications which use this media type: Not restricted to any 1319 particular application 1321 Additional information: 1323 Magic number(s): none 1324 File extension(s): An FDT Instance may use the extension ".fdt" 1325 but this is not required. 1326 Macintosh File Type Code(s): none 1328 Person & email address to contact for further information: Toni Paila 1329 (toni.paila (at) nokia.com) 1331 Intended usage: Common 1333 Author/Change controller: Toni Paila (toni.paila (at) nokia.com) 1335 8.3. Content Encoding Algorithm Registration Request 1337 Values of Content Encoding Algorithms are subject to IANA 1338 registration. The value of Content Encoding Algorithm is a numeric 1339 non-negative index. In this document, the range of values for 1340 Content Encoding Algorithms is 0 to 255. This specification already 1341 assigns the values 0, 1, 2 and 3 as described in section 3.4.3. 1343 8.3.1. Explicit IANA Assignment Guidelines 1345 This document defines a name-space for Content Encoding Algorithms 1346 named: 1348 ietf:rmt:cenc 1350 IANA has established and manages the new registry for the "ietf:rmt: 1351 cenc" name-space. The values that can be assigned within the "ietf: 1352 rmt:cenc" name-space are numeric indexes in the range [0, 255], 1353 boundaries included. Assignment requests are granted on a 1354 "Specification Required" basis as defined in RFC 2434 [11]. Note 1355 that the values 0, 1, 2 and 3 of "ietf:rmt:cenc" are already assigned 1356 by this document as described in section 3.4.3. 1358 9. Acknowledgements 1360 The following persons have contributed to this specification: Brian 1361 Adamson, Mark Handley, Esa Jalonen, Roger Kermode, Juha-Pekka Luoma, 1362 Topi Pohjolainen, Lorenzo Vicisano, and Mark Watson. The authors 1363 would like to thank all the contributors for their valuable work in 1364 reviewing and providing feedback regarding this specification. 1366 10. Contributors 1368 Jani Peltotalo 1369 Tampere University of Technology 1370 P.O. Box 553 (Korkeakoulunkatu 1) 1371 Tampere FIN-33101 1372 Finland 1373 Email: jani.peltotalo (at) tut.fi 1375 Sami Peltotalo 1376 Tampere University of Technology 1377 P.O. Box 553 (Korkeakoulunkatu 1) 1378 Tampere FIN-33101 1379 Finland 1380 Email: sami.peltotalo (at) tut.fi 1381 Magnus Westerlund 1382 Ericsson Research 1383 Ericsson AB 1384 SE-164 80 Stockholm 1385 Sweden 1386 EMail: magnus.westerlund (at) ericsson.com 1388 Thorsten Lohmar 1389 Ericsson Research (EDD) 1390 Ericsson Allee 1 1391 52134 Herzogenrath, Germany 1392 EMail: thorsten.lohmar (at) ericsson.com 1394 11. Change Log 1396 11.1. RFC3926 to draft-ietf-rmt-flute-revised-01 1398 Removed the 'Statement of Intent' from the Section 1. The statement 1399 of intent was meant to clarify the "Experimental" status of RFC3926. 1400 It does not apply to this draft that is intended for "Standard Track" 1401 submission. 1403 Added clarification on XML-DSIG in the end of Section 3. 1405 Revised the use of word "complete" in the Section 3.2. 1407 Clarified Figure 1 vrt. "Encoding Symbol(s) for FDT Instance". 1409 Clarified the FDT Instance ID wrap-around in the end of 1410 Section 3.4.1. 1412 Clarification for "Complete FDT" in the Section 3.4.2. 1414 Added semantics for the case two TOIs refer to same Content-Location. 1415 Now it is in line how 3GPP and DVB interpret the case. 1417 In the Section 3.4.2 XML Schema of FDT instance is modified to 1418 various advices. For example, extension by element was missing but 1419 is now supported. Also namespace definition is changed to URN 1420 format. 1422 Clarified FDT-schema extensibility in the end of Section 3.4.2. 1424 The CENC value allocation is added in the end of Section 3.4.3. 1426 Section 5 is modified so that EXT_FTI and the FEC issues are replaced 1427 by a reference to LCT specification. We count on revised LCT 1428 specification to specify the EXT_FTI. 1430 Added a clarifying paragraph on the use of Codepoint in the very end 1431 of Section 5. 1433 Reworked Section 8 - IANA Considerations. Now it contains three IANA 1434 registration requests: 1436 * Registration Request for XML Schema of FDT Instance 1437 (urn:ietf:params:xml:schema:fdt) 1439 * Media-Type Registration Request for application/fdt+xml 1441 * Content Encoding Algorithm Registration Request (ietf:rmt:cenc) 1443 Added Section 10 - Contributors. 1445 Added three Normative References: [9], [10], [11]. 1447 Deleted one Normative Reference: Compact FEC Schemes. 1449 12. References 1451 12.1. Normative references 1453 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1454 Levels", RFC 2119, BCP 14, March 1997. 1456 [2] Luby, M., Watson, M., and L. Vicisano, "Asynchronous Layered 1457 Coding (ALC) Protocol Instantiation", 1458 draft-ietf-rmt-pi-alc-revised-03 (work in progress), 1459 April 2006. 1461 [3] Luby, M., Watson, M., and L. Vicisano, "Layered Coding 1462 Transport (LCT) Building Block", 1463 draft-ietf-rmt-bb-lct-revised-04 (work in progress), June 2006. 1465 [4] Watson, M., Luby, M., and L. Vicisano, "Forward Error 1466 Correction (FEC) Building Block", 1467 draft-ietf-rmt-fec-bb-revised-02 (work in progress), 1468 October 2005. 1470 [5] Mills, D., "Network Time Protocol (Version 3), Specification, 1471 Implementation and Analysis", RFC 1305, March 1992. 1473 [6] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 1474 Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- 1475 HTTP/1.1", RFC 2616, June 1999. 1477 [7] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, "XML 1478 Schema Part 1: Structures", W3C Recommendation, May 2001. 1480 [8] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes", 1481 W3C Recommendation, May 2001. 1483 [9] Murata, M., St.Laurent, S., and D. Kohn, "XML Media Types", 1484 RFC 3023, January 2001. 1486 [10] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 1487 RFC 2279, January 1998. 1489 [11] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 1490 Considerations Section in RFCs", RFC 2434, October 1998. 1492 12.2. Informative references 1494 [12] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format 1495 Specification version 3.3", RFC 1950, May 1996. 1497 [13] Handley, M., Perkins, C., and E. Whelan, "Session Announcement 1498 Protocol", RFC 2974, October 2000. 1500 [14] Handley, M. and V. Jacobson, "Session Description Protocol", 1501 RFC 2327, April 1998. 1503 [15] Deering, S., "Host Extensions for IP Multicasting", RFC 1112, 1504 STD 5, August 1989. 1506 [16] Holbrook, H., "A Channel Model for Multicast, Ph.D. 1507 Dissertation, Stanford University, Department of Computer 1508 Science, Stanford, California", August 2001. 1510 [17] Deutsch, P., "DEFLATE Compressed Data Format Specification 1511 version 1.3", RFC 1951, May 1996. 1513 [18] Deutsch, P., "GZIP file format specification version 4.3", 1514 RFC 1952, May 1996. 1516 [19] Ramsdell, B., "S/MIME Version 3 Message Specification", 1517 RFC 2633, June 1999. 1519 [20] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup 1520 Language) XML-Signature Syntax and Processing", RFC 3275, 1521 March 2002. 1523 [21] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet 1524 Mail Extensions (MIME) Part Four: Registration Procedures", 1525 RFC 2048, November 1996. 1527 [22] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1528 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1529 session initiation protocol", RFC 3261, June 2002. 1531 [23] Mealling, M., "The IETF XML Registry", RFC 3688, January 2004. 1533 [24] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards 1534 (PKCS) #1: RSA Cryptography Specifications Version 2.1", 1535 RFC 3447, February 2003. 1537 [25] Kent, S., "IP Authentication Header", RFC 4302, December 2005. 1539 [26] Kent, S., "Encapsulating Security Payload (ESP)", RFC 4303, 1540 December 2005. 1542 [27] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing 1543 for Message Authentication", RFC 2104, February 1997. 1545 [28] Perrig, A., Canetti, R., Tygar, J D., and B. Briscoe, "Timed 1546 Efficient Stream Loss-Tolerant Authentication (TESLA): 1547 Multicast Source Authentication Transform Introduction", 1548 RFC 4082, June 2005. 1550 Appendix A. Receiver operation (informative) 1552 This section gives an example how the receiver of the file delivery 1553 session may operate. Instead of a detailed state-by-state 1554 specification the following should be interpreted as a rough sequence 1555 of an envisioned file delivery receiver. 1557 1. The receiver obtains the description of the file delivery session 1558 identified by the pair: (source IP address, Transport Session 1559 Identifier). The receiver also obtains the destination IP 1560 addresses and respective ports associated with the file delivery 1561 session. 1563 2. The receiver joins the channels in order to receive packets 1564 associated with the file delivery session. The receiver may 1565 schedule this join operation utilizing the timing information 1566 contained in a possible description of the file delivery session. 1568 3. The receiver receives ALC/LCT packets associated with the file 1569 delivery session. The receiver checks that the packets match the 1570 declared Transport Session Identifier. If not, packets are 1571 silently discarded. 1573 4. While receiving, the receiver demultiplexes packets based on 1574 their TOI and stores the relevant packet information in an 1575 appropriate area for recovery of the corresponding file. 1576 Multiple files can be reconstructed concurrently. 1578 5. Receiver recovers an object. An object can be recovered when an 1579 appropriate set of packets containing Encoding Symbols for the 1580 transmission object have been received. An appropriate set of 1581 packets is dependent on the properties of the FEC Encoding ID and 1582 FEC Instance ID, and on other information contained in the FEC 1583 Object Transmission Information. 1585 6. If the recovered object was an FDT Instance with FDT Instance ID 1586 'N', the receiver parses the payload of the instance 'N' of FDT 1587 and updates its FDT database accordingly. The receiver 1588 identifies FDT Instances within a file delivery session by the 1589 EXT_FDT header extension. Any object that is delivered using 1590 EXT_FDT header extension is an FDT Instance, uniquely identified 1591 by the FDT Instance ID. Note that TOI '0' is exclusively 1592 reserved for FDT delivery. 1594 7. If the object recovered is not an FDT Instance but a file, the 1595 receiver looks up its FDT database to get the properties 1596 described in the database, and assigns file with the given 1597 properties. The receiver also checks that received content 1598 length matches with the description in the database. Optionally, 1599 if MD5 checksum has been used, the receiver checks that 1600 calculated MD5 matches with the description in the FDT database. 1602 8. The actions the receiver takes with imperfectly received files 1603 (missing data, mismatching digestive, etc.) is outside the scope 1604 of this specification. When a file is recovered before the 1605 associated file description entry is available, a possible 1606 behavior is to wait until an FDT Instance is received that 1607 includes the missing properties. 1609 9. If the file delivery session end time has not been reached go 1610 back to 3. Otherwise end. 1612 Appendix B. Example of FDT Instance (informative) 1614 1615 1619 1623 1631 1633 Authors' Addresses 1635 Toni Paila 1636 Nokia 1637 102 Corporate Park Drive 1638 White Plains, NY 10604 1639 USA 1641 Email: toni.paila (at) nokia.com 1643 Rod Walsh 1644 Nokia 1645 Visiokatu 1 1646 Tampere FIN-33720 1647 Finland 1649 Email: rod.walsh (at) nokia.com 1650 Michael Luby 1651 Digital Fountain 1652 39141 Civic Center Dr. 1653 Suite 300 1654 Fremont, CA 94538 1655 USA 1657 Email: luby (at) digitalfountain.com 1659 Rami Lehtonen 1660 TeliaSonera 1661 Hatanpaan valtatie 18 1662 Tampere FIN-33100 1663 Finland 1665 Email: rami.lehtonen (at) teliasonera.com 1667 Vincent Roca 1668 INRIA Rhone-Alpes 1669 655, av. de l'Europe 1670 Montbonnot 1671 St Ismier cedex 38334 1672 France 1674 Email: vincent.roca (at) inrialpes.fr 1676 Full Copyright Statement 1678 Copyright (C) The IETF Trust (2007). 1680 This document is subject to the rights, licenses and restrictions 1681 contained in BCP 78, and except as set forth therein, the authors 1682 retain all their rights. 1684 This document and the information contained herein are provided on an 1685 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1686 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1687 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1688 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1689 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1690 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1692 Intellectual Property 1694 The IETF takes no position regarding the validity or scope of any 1695 Intellectual Property Rights or other rights that might be claimed to 1696 pertain to the implementation or use of the technology described in 1697 this document or the extent to which any license under such rights 1698 might or might not be available; nor does it represent that it has 1699 made any independent effort to identify any such rights. Information 1700 on the procedures with respect to rights in RFC documents can be 1701 found in BCP 78 and BCP 79. 1703 Copies of IPR disclosures made to the IETF Secretariat and any 1704 assurances of licenses to be made available, or the result of an 1705 attempt made to obtain a general license or permission for the use of 1706 such proprietary rights by implementers or users of this 1707 specification can be obtained from the IETF on-line IPR repository at 1708 http://www.ietf.org/ipr. 1710 The IETF invites any interested party to bring to its attention any 1711 copyrights, patents or patent applications, or other proprietary 1712 rights that may cover technology that may be required to implement 1713 this standard. Please address the information to the IETF at 1714 ietf-ipr@ietf.org. 1716 Acknowledgment 1718 Funding for the RFC Editor function is provided by the IETF 1719 Administrative Support Activity (IASA).